本文轉(zhuǎn)載自微信公眾號「Java極客技術(shù)」，作者鴨血粉絲。轉(zhuǎn)載本文請聯(lián)系Java極客技術(shù)公眾號。   

阿粉最近接到了一個面試，但是面試結(jié)果不是很盡如人意，因為雖然有些問題回答的還湊活，但是因為面試官問了一些后序的內(nèi)容，阿粉不會，于是就被吊起來瘋狂捶打了半天，敗興而歸。

[[360712]]

面試題1：HashMap和ConcurrentHashMap的區(qū)別

我們都知道HashMap是線程不安全的，當(dāng)我們在有并發(fā)的情況下去使用HashMap的put，還有g(shù)et等一些方法的時候，CPU直接飆升，而且也沒有辦法保證線程的安全性，但是更加安全的HashTable呢?

因為在HashTable里面put和get的方法的，沒一個都是加上了synchronize，雖然保證了線程的安全性，但是效率就比較低下了，在我們進(jìn)行并發(fā)訪問的時候，每次只能是一個線程進(jìn)行操作，其他的線程就只能是阻塞執(zhí)行，所以，他的效率相對來說，是非常低的，這時候我們就出現(xiàn)了ConcurrentHashMap。

而ConcurrentHashMap則使用了鎖分段(減小鎖范圍)、CAS(樂觀鎖，減小上下文切換開銷，無阻塞)等等技術(shù)，這時候你回答了，就出現(xiàn)了一環(huán)套一環(huán)的操作，那么你就分別來說說把。

在JDK1.7中，ConcurrentHashMap使用的鎖分段技術(shù)，將數(shù)據(jù)分成一段一段的存儲，然后給每一段數(shù)據(jù)配一把鎖，當(dāng)一個線程占用鎖訪問其中一個段數(shù)據(jù)的時候，其他段的數(shù)據(jù)也能被其他線程訪問。

在JDK1.8中，ConcurrentHashMap采用CAS和synchronized方式處理并發(fā)。以put操作為例，CAS方式確定key的數(shù)組下標(biāo)，synchronized保證鏈表節(jié)點的同步效果

阿粉也沒怎么墨跡，直接說能給我一張紙么?于是阿粉畫了一個之前在網(wǎng)上看的圖。

阿粉給面試官介紹的時候直接就從圖上介紹了，而阿粉直接分析源碼的時候，剛開始Segment繼承了ReentrantLock的時候，面試官就打斷了我接下來要敘述的內(nèi)容，讓我直接就說1.8的了。

1.8中的：

• 首先new一個新的hash表(nextTable)出來，大小是原來的2倍。后面的rehash都是針對這個新的hash表操作，不涉及原h(huán)ash表(table)。
• 然后會對原h(huán)ash表(table)中的每個鏈表進(jìn)行rehash，此時會嘗試獲取頭節(jié)點的鎖。這一步就保證了在rehash的過程中不能對這個鏈表執(zhí)行put操作。
• 通過sizeCtl控制，使擴(kuò)容過程中不會new出多個新hash表來。
• 最后，將所有鍵值對重新rehash到新表(nextTable)中后，用nextTable將table替換。這就避免了HashMap中g(shù)et和擴(kuò)容并發(fā)時，可能get到null的問題。
• 在整個過程中，共享變量的存儲和讀取全部通過volatile或CAS的方式，保證了線程安全。

而至于分析源碼，阿粉不再進(jìn)行分析了，以后在遇到面試的時候分析源碼的時候在繼續(xù)給大家說。畢竟下面還有很多內(nèi)容。

面試題2：你對著兩種方式的看法是什么，為什么1.8要改變呢?優(yōu)點是哪里呢?

阿粉就猜測到可能這么問，畢竟你開了頭了，你都區(qū)分出1.7和1.8了，必然會有面試官會這么問你，阿粉是這么回答的。

(1) 減少內(nèi)存開銷

假設(shè)使用可重入鎖，那么每個節(jié)點都需要繼承AQS，但并不是每個節(jié)點都需要同步支持，只有鏈表的頭節(jié)點(紅黑樹的根節(jié)點)需要同步，這無疑消耗巨大內(nèi)存。

(2) 獲得JVM的支持

可重入鎖畢竟是API級別的，后續(xù)的性能優(yōu)化空間很小。synchronized則是JVM直接支持的，JVM能夠在運行時作出相應(yīng)的優(yōu)化措施：鎖粗化、鎖消除、鎖自旋等等。使得synchronized能夠隨著JDK版本的升級而不改動代碼的前提下獲得性能上的提升。

也是虧了阿粉在面試之前的時候看過很多這樣的文章，很多東西都專門去比對了一下，于是第二個問題結(jié)束了。

面試題3：你們是怎么避免 SQL 注入的?

阿粉看到這個問題的時候，第一反應(yīng)就是肯定是按照我簡歷上寫的問的，因為阿粉之前的公司就是對安全性要求比較高的，像什么SQL注入啦，像跨站攻擊啦，于是阿粉就開始說了。

阿粉在之前的時候時候最多使用的是 where條件后面加上個1=1然后再繼續(xù)寫自己的參數(shù)。

• 確認(rèn)每種數(shù)據(jù)的類型，比如是數(shù)字，數(shù)據(jù)庫則必須使用int類型來存儲
• 嚴(yán)格限制數(shù)據(jù)庫權(quán)限
• 過濾參數(shù)中含有的一些數(shù)據(jù)庫關(guān)鍵詞

比如說過濾一些 and，char，這些在數(shù)據(jù)庫語句中是關(guān)鍵字的一些詞。

也可能面試官對這些數(shù)據(jù)安全的方面不是太注重，所以，阿粉回答出這幾種方式之后，就已經(jīng)算是完事了，也沒有繼續(xù)再往下深究。

面試題4：說一下 MySQL常用的引擎都有哪些?

數(shù)據(jù)庫存儲引擎是數(shù)據(jù)庫底層軟件組織，數(shù)據(jù)庫管理系統(tǒng)(DBMS)使用數(shù)據(jù)引擎進(jìn)行創(chuàng)建、查詢、更新和刪除數(shù)據(jù)。不同的存儲引擎提供不同的存儲機(jī)制、索引技巧、鎖定水平等功能，使用不同的存儲引擎，還可以 獲得特定的功能。現(xiàn)在許多不同的數(shù)據(jù)庫管理系統(tǒng)都支持多種不同的數(shù)據(jù)引擎。存儲引擎主要有：1. MyIsam , 2. InnoDB, 3. Memory, 4. Archive, 5. Federated 。

 關(guān)于這個阿粉就不再給大家說了，給大家安排上幾張圖：

面試題5：看你簡歷上說用過redis，那么你說一下redis的持久化的方式吧。

• RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進(jìn)行快照存儲.
• AOF持久化方式記錄每次對服務(wù)器寫的操作,當(dāng)服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進(jìn)行后臺重寫,使得AOF文件的體積不至于過大.

RDB其實就是把數(shù)據(jù)以快照的形式保存在磁盤上。什么是快照呢，你可以理解成把當(dāng)前時刻的數(shù)據(jù)拍成一張照片保存下來。

RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。也是默認(rèn)的持久化方式，這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進(jìn)制文件中,默認(rèn)的文件名為dump.rdb。

而關(guān)于怎么觸發(fā)，這個就直接去修改redis.conf配置文件即可。

AOF持久化，實際上就是追加保存每次寫的操作到文件末尾，也可能阿粉在實際的使用Redis的時候，并沒有去做過持久化的操作，回答到這里已經(jīng)算是沒有其他的了，而接下來面試官問的幾個關(guān)于Redis的問題就回答不是特別的好了，所以在Redis上面，還是得下功夫呀。

面試題6：JVM的內(nèi)存結(jié)構(gòu)，還有就是不同代的算法。

阿粉在之前的文章已經(jīng)算是分析的非常的透徹了，所以在這里阿粉就把之前的鏈接送上，大家可以看一下。

面試的時候按照這個套路回答 Java GC 的相關(guān)問題一定能過!