第二十五問: 請簡述動態代理的幾種實現方式,它們分別是什麼以及區別?
在java中,動態代理有兩種主要的實現方式，分別爲：JDK 動態代理和 CGLIB 動態代理.
JDK 動態代理就是基於 JDK 實現的代理模式，主要運用了其攔截器和反射機制，其代理對象是由 JDK 動態生成的，而不像靜態代理方式寫死代理對象和被代理類。JDK 代理是不需要第三方庫支持的，只需要 JDK 環境就可以進行代理，使用條件：
1.被代理的對象必須要實現接口;(可以直接說這一句,)
2.使用Proxy.newProxyInstance產生代理對象；
3.必須實現InvocationHandler接口；
是CGLIB 動態代理利用ASM開源包，對代理對象類的class文件加載進來，通過修改其字節碼生成子類來處理。
1.被代理的對象不用實現接口;(可以直接說這一句,)
2.CGLIB 必須依賴於 CGLIB 的類庫，其爲需要被代理的類生成一個子類，覆蓋其中的方法，實際上是一種繼承
主要區別:
JDK 動態代理只能對實現了接口的類生成代理，而不能針對類;
CGLIB 是針對類實現代理，主要是對指定的類生成一個子類，覆蓋其中的方法，並覆蓋其中方法實現增強，但是因爲採用的是繼承，所以該類或方法最好不要聲明成final，對於final類或方法，是無法繼承的.
第二十六問: 你瞭解java的雙親委派機制嗎?,請大概簡述一下?
我們在加載一個類的時候，它並不會第一時間自己先去加載，而是去委託給父類的加載器去執行，一旦如果父類加載器還存在其父類加載器，依次遞歸詢問，直到到達最頂層的啓動類加載器，如果父類加載器可以完成類加載任務，就成功返回，如果不能，那子加載器纔會嘗試自己去加載，這就是所謂的雙親委派模式.
那麼這樣做的好處是因爲 :
1.類隨着它的類加載器一起具備了一種帶有優先級的層次關係，通過這種層級關可以避免類的重複加載，當父親已經加載了該類時，就沒有必要子ClassLoader再加載一次
2.因爲我們在加載類的時候,有很多核心庫已經是自帶的,如果是自己能加載,那麼會導致核心API庫被隨意篡改,這樣是不安全的,所以使用雙親委託模式將傳遞到啓動類加載器，而啓動類加載器在覈心Java API發現這個名字的類，發現該類已被加載，並不會重新加載網絡傳遞的過來的.
第二十七問: 你知道事務傳播行爲嗎 ?spring中支持哪些事務傳播行爲?
事務傳播行爲就是當一個事務方法被另一個事務方法調用時，這個事務方法應該如何進行.
目前Spring支持7中事務傳播行爲
propagation_required（需要傳播）：當前沒有事務則新建事務，有則加入當前事務
propagation_supports（支持傳播）：支持當前事務，如果當前沒有事務則以非事務方式執行
propagation_mandatory（強制傳播）：使用當前事務，如果沒有則拋出異常
propagation_nested（嵌套傳播）：如果當前存在事務，則在嵌套事務內執行，如果當前沒有事務，則執行需要傳播行爲。
propagation_never（絕不傳播）：以非事務的方式執行，如果當前有事務則拋出異常
propagation_requires_new（傳播需要新的）：新建事務，如果當前有事務則把當前事務掛起
propagation_not_supported（不支持傳播）：以非事務的方式執行，如果當前有事務則把當前事務掛起
第二十八問: 你瞭解redis的持久化嗎?簡單概敘一下?
RDB（半持久化方式）：按照配置不定期的通過異步的方式、快照的形式直接把內存中的數據持久化到磁盤的一個dump.rdb文件（二進制的臨時文件）中，redis默認的持久化方式，它在配置文件（redis.conf）中。
優點：只包含一個文件，將一個單獨的文件轉移到其他存儲媒介上，對於文件備份、災難恢復而言，比較實用。
缺點：系統一旦在持久化策略之前出現宕機現象，此前沒有來得及持久化的數據將會產生丟失
AOF（全持久化的方式）：把每一次數據變化都通過write()函數將你所執行的命令追加到一個appendonly.aof文件裏面，Redis默認是不支持這種全持久化方式的，需要在配置文件（redis.conf）中將appendonly no改成appendonly yes
優點：數據安全性高，對日誌文件的寫入操作採用的是append模式，因此在寫入過程中即使出現宕機問題，也不會破壞日誌文件中已經存在的內容；
缺點：對於數量相同的數據集來說，aof文件通常要比rdb文件大，因此rdb在恢復大數據集時的速度大於AOF；
加分項(面試官要是感興趣可以在說下面這些)
在Redis的配置文件中存在三種同步方式，它們分別是：
1. appendfsync always 每次有數據修改發生時都會都調用fsync刷新到aof文件，非常慢，但是安全；
2. appendfsync everysec 每秒鐘都調用fsync刷新到aof文件中，很快，但是可能丟失一秒內的數據，推薦使用，兼顧了速度和 安全；
3. appendfsync no 不會自動同步到磁盤上，需要依靠OS（操作系統）進行刷新，效率快，但是安全性就比較差；
二種持久化方式區別：
1.AOF在運行效率上往往慢於RDB，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效；
2.如果緩存數據安全性要求比較高的話，用aof這種持久化方式（比如項目中的購物車）；
3.如果對於大數據集要求效率高的話，就可以使用默認的。而且這兩種持久化方式可以同時使用。
第二十九問: 緩存穿透和緩存雪崩知道嗎?如何避免這種情況?
緩存穿透:
一般的當我們通過鍵去查詢對應的值,如果緩存中沒有 ,就會去數據庫,一旦數據庫中也沒有,並且這個通過鍵去查詢併發請求很大，就會對數據庫產生很大的壓力，這就叫緩存穿透.
緩存雪崩:
當緩存服務器重啓或者大量緩存集中在一段時間內失效，發生大量的緩存穿透，這樣在失效的瞬間對數據庫的訪問壓力就比較大，所有的查詢都落在數據庫上，造成了緩存雪崩。
如何解決:
緩存穿透解決方案:
1.對所有可能查詢的參數以hash形式存儲，在控制層先進行校驗，不符合則丟棄。
2.將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存 儲系統的查詢壓力。
3.如果一個查詢返回的數據爲空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會 很短，最長不超過五分鐘。
緩存雪崩解決方案:
1.在緩存失效後，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其 他線程等待。
2.可以通過緩存reload機制，預先去更新緩存，再即將發生大併發訪問前手動觸發加載緩存
3.不同的key，設置不同的過期時間，讓緩存失效的時間點儘量均勻
4.做二級緩存，或者雙緩存策略。A1爲原始緩存，A2爲拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設置爲短期，A2 設置爲長期。
第三十問: cookie和session的區別，分佈式環境怎麼保存用戶狀態況?
Cookie
Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器，是一種在客戶端保持狀態的方案。
Session
Session是存在服務器的一種用來存放用戶數據的類HashTable結構。
區別：
Cookie存在客戶端所以用戶可以看見，所以也可以編輯僞造，不是十分安全。
Session存在服務端過多的時候會消耗服務器資源，所以大型網站會有專門的Session服務器
分佈式環境怎麼保存用戶狀態：
第一種： 粘性Session( 常用Nginx鎖定Session)
原理：粘性Session是指將用戶鎖定到某一個服務器上，比如上面說的例子，用戶第一次請求時，負載均衡器將用戶的請求轉發到了A服務器上，如果負載均衡器設置了粘性Session的話，那麼用戶以後的每次請求都會轉發到A服務器上，相當於把用戶和A服務器粘到了一塊，這就是粘性Session機制。
優點：簡單，不需要對session做任何處理。
缺點：缺乏容錯性，如果當前訪問的服務器發生故障，用戶被轉移到第二個服務器上時，他的session信息都將失效。
適用場景：發生故障對客戶產生的影響較小；服務器發生故障是低概率事件。
第二種：session持久化到數據庫
原理：就不用多說了吧，拿出一個數據庫，專門用來存儲session信息。保證session的持久化。
優點：服務器出現問題，session不會丟失
缺點：如果網站的訪問量很大，把session存儲到數據庫中，會對數據庫造成很大壓力，還需要增加額外的開銷維護數據庫。
未完待續.....