结合项目
1. spring-shiro 权限问题
使用Shiro Filter 将Shiro和spring整合
<bean id="filterProxy" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
<!-- 配置的众多filter，只要匹配上了前面的一个，后面的都不会进入了 -->
<bean id="shiroMetaSource" class="com.zhaojiaxiu.framework.shiro.ShiroMetaSource">
2.使用redis的好处 原理 代码
Redis是一个开源的，基于内存的结构化数据存储媒介，可以作为数据库、缓存服务或消息服务使用。
Redis支持多种数据结构，包括字符串 string、哈希表 hash、链表list、集合set、有序集合sorted set、位图、Hyperloglogs等。
Redis具备LRU淘汰、事务实现、以及不同级别的硬盘持久化等能力，并且支持副本集和通过Redis Sentinel实现的高可用方案，同时还支持通过Redis Cluster实现的数据自动分片能力。
Redis的主要功能都基于单线程模型实现，也就是说Redis使用一个线程来服务所有的客户端请求，同时Redis采用了非阻塞式IO，并精细地优化各种命令的算法时间复杂度
前文提到过，Redis采用单线程模型，天然是线程安全的，这使得INCR/DECR命令可以非常便利的实现高并发场景下的精确控制。
代码：spring-data-redis
/** * Increments the number stored at field in the hash stored at key by increment. * * @param key key * @param field field * @param increment 增量 * @return 操作后的值 */ public Long hIncrBy(final String key, final String field, final Long increment) { return (Long) redisTemplate.<Long>execute((RedisCallback<Long>) connection -> connection.hIncrBy(key.getBytes(), field.getBytes(), increment) ); }
3.使用ActiveMQ的好处,原理 代码 5.13.0
ActiveMQ持久化节点
3. KahaDB方式
KahaDB是从ActiveMQ 5.4开始默认的持久化插件，也是我们项目现在使用的持久化方式。
KahaDb恢复时间远远小于其前身AMQ并且使用更少的数据文件，所以可以完全代替AMQ。
kahaDB的持久化机制同样是基于日志文件，索引和缓存。
配置方式：
|
1
2
3
4
5
|
<
persistenceAdapter
>
<
kahaDB
directory="${activemq.data}/activemq-data" journalMaxFileLength="16mb"/>
</
persistenceAdapter
>
directory : 指定持久化消息的存储目录
journalMaxFileLength : 指定保存消息的日志文件大小，具体根据你的实际应用配置
|
（1）KahaDB主要特性
1、日志形式存储消息；
2、消息索引以B-Tree结构存储，可以快速更新；
3、完全支持JMS事务；
4、支持多种恢复机制；
（2）KahaDB的结构
消息存储在基于文件的数据日志中。如果消息发送成功，变标记为可删除的。系统会周期性的清除或者归档日志文件。
消息文件的位置索引存储在内存中，这样能快速定位到。定期将内存中的消息索引保存到metadata store中，避免大量消息未发送时，消息索引占用过多内存空间。
Data logs：
Data logs用于存储消息日志，消息的全部内容都在Data logs中。
同AMQ一样，一个Data logs文件大小超过规定的最大值，会新建一个文件。同样是文件尾部追加，写入性能很快。
每个消息在Data logs中有计数引用，所以当一个文件里所有的消息都不需要了，系统会自动删除文件或放入归档文件夹。
Metadata cache ：
缓存用于存放在线消费者的消息。如果消费者已经快速的消费完成，那么这些消息就不需要再写入磁盘了。
Btree索引会根据MessageID创建索引，用于快速的查找消息。这个索引同样维护持久化订阅者与Destination的关系，以及每个消费者消费消息的指针。
Metadata store
在db.data文件中保存消息日志中消息的元数据，也是以B-Tree结构存储的，定时从Metadata cache更新数据。Metadata store中也会备份一些在消息日志中存在的信息，这样可以让Broker实例快速启动。
即便metadata store文件被破坏或者误删除了。broker可以读取Data logs恢复过来，只是速度会相对较慢些。
4.LevelDB方式
从ActiveMQ 5.6版本之后，又推出了LevelDB的持久化引擎。
目前默认的持久化方式仍然是KahaDB，不过LevelDB持久化性能高于KahaDB，可能是以后的趋势。
在ActiveMQ 5.9版本提供了基于LevelDB和Zookeeper的数据复制方式，用于Master-slave方式的首选数据复制方案。
ActiveMQ服务器挂掉问题解决---尽量不要用非持久化消息，非要用的话，将临时文件限制尽可能的调大
ActiveMQ丢消息问题解决--用持久化消息，或者非持久化消息及时处理不要堆积，或者启动事务，启动事务后，commit()方法会负责任的等待服务器的返回，也就不会关闭连接导致消息丢失了。
ActiveMQ.DLQ死信管理
4.Elasticsreach的好处，原理 分词器 代码
5.spring mvc spring spring boot
6.Mybaits 的优点
7.GC
8.四个系统之间的调用关系
9.jsp 和servlet
10.dubbo优点相对其他网络编程 原理
11.关键字 来控制并发操作 volied 和
12.new 对象 在jvm中存储
11.struts2的过滤器filter 和spring MVC 的拦截器Interceptor
①拦截器是基于Java的反射机制的，而过滤器是基于函数回调。
②拦截器不依赖与servlet容器，过滤器依赖与servlet容器。
③拦截器只能对action请求起作用，而过滤器则可以对几乎所有的请求起作用。
④拦截器可以访问action上下文、值栈里的对象，而过滤器不能访问。
⑤在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次。
⑥拦截器可以获取IOC容器中的各个bean，而过滤器就不行，这点很重要，在拦截器里注入一个service，可以调用业务逻辑。
两者的本质区别：拦截器是基于java的反射机制的，而过滤器是基于函数回调。
从灵活性上说拦截器功能更强大些，Filter能做的事情，他都能做，而且可以在请求前，请求后执行，比较灵活。
Filter主要是针对URL地址做一个编码的事情、过滤掉没用的参数、安全校验（比较泛的，比如登录不登录之类），太细的话，还是建议用interceptor。
不过还是根据不同情况选择合适的。