面試問題總結

結合項目

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主要特性
一、日誌形式存儲消息；
二、消息索引以B-Tree結構存儲，能夠快速更新；
三、徹底支持JMS事務；
四、支持多種恢復機制；

（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。不過仍是根據不一樣狀況選擇合適的。