1、hashMap底層？為什么jdk1.8要用紅黑樹實現？什么時候會出現線程不安全？怎么解決線程不安全？默認初始容量是16，如果我改成7，容量會變成7么？為什么？
2、數組和鏈表的區別是什么？如果一個數組大小超過堆中剩下的內存大小，還會為這個數組分配內存么？
3、常見的線程池有哪些？線程池中一個線程死了，就沒有線程了么？如果在線程池中new了一個線程，這個線程是存在還是不存在？線程池中的一些參數有哪些？newCachedPool最大可開啟的線程數是多少？
4、如何實現其他線程和主線程的同步？
5、volatile關鍵字的特性有哪些？
6、10個線程，如何實現和主線程的同步？場景是：10個人在山下聚齊之后才可以一起爬山，怎么實現？不用synchronized關鍵字、volatile等同步的關鍵字。
7、平時建mysql表的時候會考慮一些什么？
8、寫sql語句的時候where會考慮什么？
redis作為高速緩存和數據庫的數據一致性的問題，如果數據更新的話是先更新數據庫還是先更新緩存？若果先更新數據庫再更新緩存會涉及什么問題
首先，緩存由於其高並發和高性能的特性，已經在項目中被廣泛使用。在讀取緩存方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。
但是在更新緩存方面，對於更新完數據庫，是更新緩存呢，還是刪除緩存。又或者是先刪除緩存，再更新數據庫，其實大家存在很大的爭議。
先做一個說明，從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數據設置過期時間，所有的寫操作以數據庫為准，對緩存操作只是盡最大努力即可。
如果您正在學習Spring Boot，推薦一個連載多年還在繼續更新的免費教程：http://blog.didispace.com/spring-boot-learning-2x/
也就是說如果數據庫寫成功，緩存更新失敗，那么只要到達過期時間，則后面的讀請求自然會從數據庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴於給緩存設置過期時間這個方案。
在這里，我們討論三種更新策略：
- 先更新數據庫，再更新緩存
- 先刪除緩存，再更新數據庫
- 先更新數據庫，再刪除緩存
應該沒人問我，為什么沒有先更新緩存，再更新數據庫這種策略。
（1）先更新數據庫，再更新緩存
這套方案，大家是普遍反對的。為什么呢？有如下兩點原因。
- 原因一（線程安全角度）
同時有請求A和請求B進行更新操作，那么會出現
- 線程A更新了數據庫
- 線程B更新了數據庫
- 線程B更新了緩存
- 線程A更新了緩存
這就出現請求A更新緩存應該比請求B更新緩存早才對，但是因為網絡等原因，B卻比A更早更新了緩存。這就導致了臟數據，因此不考慮。
- 原因二（業務場景角度）
有如下兩點：
- 如果你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，采用這種方案就會導致，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。
- 如果你寫入數據庫的值，並不是直接寫入緩存的，而是要經過一系列復雜的計算再寫入緩存。那么，每次寫入數據庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。
接下來討論的就是爭議最大的，先刪緩存，再更新數據庫。還是先更新數據庫，再刪緩存的問題。
（2）先刪緩存，再更新數據庫
該方案會導致不一致的原因是。同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現如下情形:
- 請求A進行寫操作，刪除緩存
- 請求B查詢發現緩存不存在
- 請求B去數據庫查詢得到舊值
- 請求B將舊值寫入緩存
- 請求A將新值寫入數據庫
上述情況就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。
那么，如何解決呢？采用延時雙刪策略
偽代碼如下
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}
轉化為中文描述就是
- 先淘汰緩存
- 再寫數據庫（這兩步和原來一樣）
- 休眠1秒，再次淘汰緩存
這么做，可以將1秒內所造成的緩存臟數據，再次刪除。
那么，這個1秒怎么確定的，具體該休眠多久呢？
針對上面的情形，讀者應該自行評估自己的項目的讀數據業務邏輯的耗時。然后寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上，加幾百ms即可。這么做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存臟數據。
如果你用了mysql的讀寫分離架構怎么辦？
ok，在這種情況下，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。
- 請求A進行寫操作，刪除緩存
- 請求A將數據寫入數據庫了，
- 請求B查詢緩存發現，緩存沒有值
- 請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
- 請求B將舊值寫入緩存
- 數據庫完成主從同步，從庫變為新值
- 如果您正在學習Spring Boot，推薦一個連載多年還在繼續更新的免費教程：http://blog.didispace.com/spring-boot-learning-2x/
上述情形，就是數據不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。
采用這種同步淘汰策略，吞吐量降低怎么辦？
ok，那就將第二次刪除作為異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間后了，再返回。這么做，加大吞吐量。
第二次刪除,如果刪除失敗怎么辦？
這是個非常好的問題，因為第二次刪除失敗，就會出現如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，為了方便，假設是單庫：
- 請求A進行寫操作，刪除緩存
- 請求B查詢發現緩存不存在
- 請求B去數據庫查詢得到舊值
- 請求B將舊值寫入緩存
- 請求A將新值寫入數據庫
- 請求A試圖去刪除請求B寫入對緩存值，結果失敗了。
ok,這也就是說。如果第二次刪除緩存失敗，會再次出現緩存和數據庫不一致的問題。
如何解決呢？
具體解決方案，且看博主對第(3)種更新策略的解析。
（3）先更新數據庫，再刪緩存
首先，先說一下。老外提出了一個緩存更新套路，名為《Cache-Aside pattern》。其中就指出
- 失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
- 命中：應用程序從cache中取數據，取到后返回。
- 更新：先把數據存到數據庫中，成功后，再讓緩存失效。
另外，知名社交網站facebook也在論文《Scaling Memcache at Facebook》中提出，他們用的也是先更新數據庫，再刪緩存的策略。
這種情況不存在並發問題么？
不是的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那么會有如下情形產生
- 緩存剛好失效
- 請求A查詢數據庫，得一個舊值
- 請求B將新值寫入數據庫
- 請求B刪除緩存
- 請求A將查到的舊值寫入緩存
ok，如果發生上述情況，確實是會發生臟數據。
然而，發生這種情況的概率又有多少呢？
發生上述情況有一個先天性條件，就是步驟（3）的寫數據庫操作比步驟（2）的讀數據庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。可是，大家想想，數據庫的讀操作的速度遠快於寫操作的（不然做讀寫分離干嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。
假設，有人非要抬杠，有強迫症，一定要解決怎么辦？
如何解決上述並發問題？
首先，給緩存設有效時間是一種方案。其次，采用策略（2）里給出的異步延時刪除策略，保證讀請求完成以后，再進行刪除操作。
還有其他造成不一致的原因么？
有的，這也是緩存更新策略（2）和緩存更新策略（3）都存在的一個問題，如果刪緩存失敗了怎么辦，那不是會有不一致的情況出現么。比如一個寫數據請求，然后寫入數據庫了，刪緩存失敗了，這會就出現不一致的情況了。這也是緩存更新策略（2）里留下的最后一個疑問。
如何解決？
提供一個保障的重試機制即可，這里給出兩套方案。
方案一：
如下圖所示
流程如下所示
- 更新數據庫數據；
- 緩存因為種種問題刪除失敗
- 將需要刪除的key發送至消息隊列
- 自己消費消息，獲得需要刪除的key
- 繼續重試刪除操作，直到成功
然而，該方案有一個缺點，對業務線代碼造成大量的侵入。於是有了方案二，在方案二中，啟動一個訂閱程序去訂閱數據庫的binlog，獲得需要操作的數據。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
方案二：
流程如下圖所示：
- 更新數據庫數據
- 數據庫會將操作信息寫入binlog日志當中
- 訂閱程序提取出所需要的數據以及key
- 另起一段非業務代碼，獲得該信息
- 嘗試刪除緩存操作，發現刪除失敗
- 將這些信息發送至消息隊列
- 重新從消息隊列中獲得該數據，重試操作。
- 如果您正在學習Spring Boot，推薦一個連載多年還在繼續更新的免費教程：http://blog.didispace.com/spring-boot-learning-2x/
備注說明：
上述的訂閱binlog程序在mysql中有現成的中間件叫canal，可以完成訂閱binlog日志的功能。至於oracle中，博主目前不知道有沒有現成中間件可以使用。
另外，重試機制，博主是采用的是消息隊列的方式。如果對一致性要求不是很高，直接在程序中另起一個線程，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供一個思路。
存粒度控制
選用全量屬性，通用性會更好，也便於維護，像user表這種，用全量屬性還可以，
但我們選用緩存就需要考慮性能和空間的問題，只保存我們需要的屬性就好了（但后期表結構改了，維護性很差）
緩存穿透：（直接對存儲層操作，失去了緩存層的意義）
查詢一個數據庫中不存在的數據，比如商品詳情，查詢一個不存在的ID，每次都會訪問DB，如果有人惡意破壞，很可能直接對DB造成過大地壓力。
解決方案：
- 當通過某一個key去查詢數據的時候，如果對應在數據庫中的數據都不存在，我們將此key對應的value設置為一個默認的值，比如“NULL”，並設置一個緩存的失效時間，這時在緩存失效之前，所有通過此key的訪問都被緩存擋住了。后面如果此key對應的數據在DB中存在時，緩存失效之后，通過此key再去訪問數據，就能拿到新的value了。
- 常見的則是采用布隆過濾器（可以用很小的內存保留很多的數據），將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被 這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。（布隆過濾器：實際上是一個很長的二進制向量和一系列隨機映射函數。布隆過濾器可以用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率和刪除困難。）
關於布隆過濾器：
緩存雪崩：（緩存失效）
緩存同一時間大面積的失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
解決方案：
- 將系統中key的緩存失效時間均勻地錯開，防止統一時間點有大量的key對應的緩存失效；
- 重新設計緩存的使用方式，當我們通過key去查詢數據時，首先查詢緩存，如果此時緩存中查詢不到，就通過分布式鎖進行加鎖，取得鎖的進程查DB並設置緩存，然后解鎖；其他進程如果發現有鎖就等待，然后等解鎖后返回緩存數據或者再次查詢DB。
- 盡量保證整個 redis 集群的高可用性，發現機器宕機盡快補上
- 本地ehcache緩存 + hystrix限流&降級，避免MySQL崩掉
假如已經崩潰了：也可以利用redis的持久化機制將保存的數據盡快恢復到緩存里。
緩存無底洞：
為了滿足業務大量加節點，但是性能沒提升反而下降。
當客戶端增加一個緩存的時候，只需要 mget 一次，但是如果增加到三台緩存，這個時候則需要 mget 三次了（網絡通信的時間增加了），每增加一台，客戶端都需要做一次新的 mget，給服務器造成性能上的壓力。
同時，mget 需要等待最慢的一台機器操作完成才能算是完成了 mget 操作。這還是並行的設計，如果是串行的設計就更加慢了。
通過上面這個實例可以總結出：更多的機器！=更高的性能
但是並不是沒辦法，一般在優化 IO 的時候可以采用以下幾個方法。
- 命令的優化。例如慢查下 keys、hgetall bigkey。
- 我們需要減少網絡通訊的次數。這個優化在實際應用中使用次數是最多的，我們盡量減少通訊次數。
- 降低接入成本。比如使用客戶端長連接或者連接池、NIO 等等。
hashMap底層？為什么jdk1.8要用紅黑樹實現？什么時候會出現線程不安全？怎么解決線程不安全？默認初始容量是16，如果我改成7，容量會變成7么？？為什么？
在JDK1.6，JDK1.7中，HashMap采用位桶+鏈表實現，即使用鏈表處理沖突，同一hash值的鏈表都存儲在一個鏈表里。但是當位於一個桶中的元素較多，即hash值相等的元素較多時，通過key值依次查找的效率較低。而JDK1.8中，HashMap采用位桶+鏈表+紅黑樹實現，當鏈表長度超過閾值（8）時，將鏈表轉換為紅黑樹，這樣大大減少了查找時間。
不安全原因：
在put的時候，因為該方法不是同步的，假如有兩個線程A,B它們的put的key的hash值相同，不論是從頭插入還是從尾插入，假如A獲取了插入位置為x，但是還未插入，此時B也計算出待插入位置為x，則不論AB插入的先后順序肯定有一個會丟失 以下是put方法
在擴容的時候，jdk1.8之前是采用頭插法，當兩個線程同時檢測到hashmap需要擴容，在進行同時擴容的時候有可能會造成鏈表的循環，主要原因就是，采用頭插法，新鏈表與舊鏈表的順序是反的，在1.8后采用尾插法就不會出現這種問題，同時1.8的鏈表長度如果大於8就會轉變成紅黑樹。
默認容量為16的原因：
關於這個默認容量的選擇，JDK並沒有給出官方解釋，筆者也沒有在網上找到關於這個任何有價值的資料。（如果哪位有相關的權威資料或者想法，可以留言交流）
根據作者的推斷，這應該就是個經驗值（Experience Value），既然一定要設置一個默認的2^n 作為初始值，那么就需要在效率和內存使用上做一個權衡。這個值既不能太小，也不能太大。
如果您正在學習Spring Boot，推薦一個連載多年還在繼續更新的免費教程：http://blog.didispace.com/spring-boot-learning-2x/
太小了就有可能頻繁發生擴容，影響效率。太大了又浪費空間，不划算。
所以，16就作為一個經驗值被采用了。
常見的線程池有哪些？線程池中一個線程死了，就沒有線程了么？如果在線程池中new了一個線程，這個線程是存在還是不存在？線程池中的一些參數有哪些？newCachedPool最大可開啟的線程數是多少？
常見的線程池：
1、newCachedThreadPool
創建一個可緩存線程池，如果線程池長度超過處理需要，可靈活回收空閑線程，若無可回收，則新建線程。
這種類型的線程池特點是：
工作線程的創建數量幾乎沒有限制(其實也有限制的,數目為Interger. MAX_VALUE), 這樣可靈活的往線程池中添加線程。如果長時間沒有往線程池中提交任務，即如果工作線程空閑了指定的時間(默認為1分鍾)，則該工作線程將自動終止。終止后，如果你又提交了新的任務，則線程池重新創建一個工作線程。在使用CachedThreadPool時，一定要注意控制任務的數量，否則，由於大量線程同時運行，很有會造成系統癱瘓。
2、newFixedThreadPool
創建一個指定工作線程數量的線程池。每當提交一個任務就創建一個工作線程，如果工作線程數量達到線程池初始的最大數，則將提交的任務存入到池隊列中。FixedThreadPool是一個典型且優秀的線程池，它具有線程池提高程序效率和節省創建線程時所耗的開銷的優點。但是，在線程池空閑時，即線程池中沒有可運行任務時，它不會釋放工作線程，還會占用一定的系統資源。
3、newSingleThreadExecutor
創建一個單線程化的Executor，即只創建唯一的工作者線程來執行任務，它只會用唯一的工作線程來執行任務，保證所有任務按照指定順序(FIFO, LIFO, 優先級)執行。如果這個線程異常結束，會有另一個取代它，保證順序執行。單工作線程最大的特點是可保證順序地執行各個任務，並且在任意給定的時間不會有多個線程是活動的。
4、newScheduleThreadPool
創建一個定長的線程池，而且支持定時的以及周期性的任務執行，支持定時及周期性任務執行。
手撕代碼：
給你一個整數數組 nums 和一個正整數 k，請你判斷是否可以把這個數組划分成一些由 k 個連續數字組成的集合。
如果可以，請返回 True；否則，返回 False。
示例 1：
輸入：nums = [1,2,3,3,4,4,5,6], k = 4
輸出：true
解釋：數組可以分成 [1,2,3,4] 和 [3,4,5,6]。
示例 2：
輸入：nums = [3,2,1,2,3,4,3,4,5,9,10,11], k = 3
輸出：true
解釋：數組可以分成 [1,2,3] , [2,3,4] , [3,4,5] 和 [9,10,11]。
示例 3：
輸入：nums = [3,3,2,2,1,1], k = 3
輸出：true
示例 4：
輸入：nums = [1,2,3,4], k = 3
輸出：false
解釋：數組不能分成幾個大小為 3 的子數組。
提示：
1 <= nums.length <= 10^5
1 <= nums[i] <= 10^9
1 <= k <= nums.length
- END -