101.jvm相關(guān)參數(shù)

102.lock 钝荡，sychronized揪垄，volatile的區(qū)別

一：volatile和synchronized區(qū)別

1）volatile本質(zhì)是在告訴jvm當(dāng)前變量在寄存器中的值是不確定的,需要從主存中讀取,synchronized則是鎖定當(dāng)前變量,只有當(dāng)前線程可以訪問該變量,其他線程被阻塞住.

2）volatile僅能使用在變量級別,synchronized則可以使用在變量,方法.

3）volatile僅能實現(xiàn)變量的修改可見性,而synchronized則可以保證變量的修改可見性和原子性.《Java編程思想》上說蝙昙，定義long或double變量時杭棵，如果使用volatile關(guān)鍵字客年，就會獲得（簡單的賦值與返回操作）原子性坊罢。

?4）volatile不會造成線程的阻塞,而synchronized可能會造成線程的阻塞.

5）烤黍、當(dāng)一個域的值依賴于它之前的值時知市，volatile就無法工作了，如n=n+1,n++等速蕊。如果某個域的值受到其他域的值的限制嫂丙，那么volatile也無法工作，如Range類的lower和upper邊界规哲，必須遵循lower<=upper的限制跟啤。

6）、使用volatile而不是synchronized的唯一安全的情況是類中只有一個可變的域。

二：synchronized和lock區(qū)別

1）Lock是一個接口隅肥，而synchronized是Java中的關(guān)鍵字关顷，synchronized是內(nèi)置的語言實現(xiàn)；

2）synchronized在發(fā)生異常時武福，會自動釋放線程占有的鎖议双，因此不會導(dǎo)致死鎖現(xiàn)象發(fā)生；而Lock在發(fā)生異常時捉片，如果沒有主動通過unLock()去釋放鎖平痰，則很可能造成死鎖現(xiàn)象，因此使用Lock時需要在finally塊中釋放鎖伍纫；

3）Lock可以讓等待鎖的線程響應(yīng)中斷宗雇，而synchronized卻不行，使用synchronized時莹规，等待的線程會一直等待下去赔蒲，不能夠響應(yīng)中斷；

4）通過Lock可以知道有沒有成功獲取鎖良漱，而synchronized卻無法辦到舞虱。

5）Lock可以提高多個線程進行讀操作的效率。在性能上來說母市，如果競爭資源不激烈矾兜，兩者的性能是差不多的，而當(dāng)競爭資源非常激烈時（即有大量線程同時競爭）患久，此時Lock的性能要遠(yuǎn)遠(yuǎn)優(yōu)于synchronized椅寺。所以說，在具體使用時要根據(jù)適當(dāng)情況選擇蒋失。

103.面試必備之樂觀鎖與悲觀鎖

何謂悲觀鎖與樂觀鎖

??????? 樂觀鎖對應(yīng)于生活中樂觀的人總是想著事情往好的方向發(fā)展返帕，悲觀鎖對應(yīng)于生活中悲觀的人總是想著事情往壞的方向發(fā)展。這兩種人各有優(yōu)缺點篙挽，不能不以場景而定說一種人好于另外一種人荆萤。

??????? 悲觀鎖總是假設(shè)最壞的情況，每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改嫉髓，所以每次在拿數(shù)據(jù)的時候都會上鎖观腊，這樣別人想拿這個數(shù)據(jù)就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞算行，用完后再把資源轉(zhuǎn)讓給其它線程）。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機制苫耸，比如行鎖州邢，表鎖等，讀鎖，寫鎖等量淌，都是在做操作之前先上鎖骗村。Java中synchronized和ReentrantLock等獨占鎖就是悲觀鎖思想的實現(xiàn)。

??????? 樂觀鎖總是假設(shè)最好的情況呀枢，每次去拿數(shù)據(jù)的時候都認(rèn)為別人不會修改胚股，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)裙秋，可以使用版本號機制和CAS算法實現(xiàn)琅拌。樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量摘刑，像數(shù)據(jù)庫提供的類似于write_condition機制进宝，其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現(xiàn)方式CAS實現(xiàn)的枷恕。

兩種鎖的使用場景

??????? 從上面對兩種鎖的介紹党晋，我們知道兩種鎖各有優(yōu)缺點，不可認(rèn)為一種好于另一種徐块，像樂觀鎖適用于寫比較少的情況下（多讀場景）未玻，即沖突真的很少發(fā)生的時候，這樣可以省去了鎖的開銷胡控，加大了系統(tǒng)的整個吞吐量深胳。但如果是多寫的情況，一般會經(jīng)常產(chǎn)生沖突铜犬，這就會導(dǎo)致上層應(yīng)用會不斷的進行retry舞终，這樣反倒是降低了性能，所以一般多寫的場景下用悲觀鎖就比較合適癣猾。

樂觀鎖常見的兩種實現(xiàn)方式：

??????? 樂觀鎖一般會使用版本號機制或CAS算法實現(xiàn)敛劝。

??????? 1. 版本號機制一般是在數(shù)據(jù)表中加上一個數(shù)據(jù)版本號version字段，表示數(shù)據(jù)被修改的次數(shù)纷宇，當(dāng)數(shù)據(jù)被修改時夸盟，version值會加一。當(dāng)線程A要更新數(shù)據(jù)值時像捶，在讀取數(shù)據(jù)的同時也會讀取version值上陕，在提交更新時，若剛才讀取到的version值為當(dāng)前數(shù)據(jù)庫中的version值相等時才更新拓春，否則重試更新操作释簿，直到更新成功蕊玷。

??????? 2. CAS算法即compare and swap（比較與交換）柳击，是一種有名的無鎖算法。無鎖編程垒棋，即不使用鎖的情況下實現(xiàn)多線程之間的變量同步，也就是在沒有線程被阻塞的情況下實現(xiàn)變量的同步偏螺，所以也叫非阻塞同步（Non-blocking Synchronization）行疏。CAS算法涉及到三個操作數(shù)

??????? （1）需要讀寫的內(nèi)存值 V

??????? （2）進行比較的值 A

??????? （3）擬寫入的新值 B

??????? 當(dāng)且僅當(dāng) V 的值等于 A時，CAS通過原子方式用新值B來更新V的值套像，否則不會執(zhí)行任何操作（比較和替換是一個原子操作）酿联。一般情況下是一個自旋操作，即不斷的重試夺巩。

樂觀鎖的缺點

??????? ABA 問題是樂觀鎖一個常見的問題

??????? 1 ABA 問題

??????? 如果一個變量V初次讀取的時候是A值贞让，并且在準(zhǔn)備賦值的時候檢查到它仍然是A值，那我們就能說明它的值沒有被其他線程修改過了嗎劲够？很明顯是不能的震桶，因為在這段時間它的值可能被改為其他值，然后又改回A征绎，那CAS操作就會誤認(rèn)為它從來沒有被修改過蹲姐。這個問題被稱為CAS操作的 “ABA”問題。JDK 1.5 以后的 AtomicStampedReference 類就提供了此種能力人柿，其中的 compareAndSet 方法就是首先檢查當(dāng)前引用是否等于預(yù)期引用柴墩，并且當(dāng)前標(biāo)志是否等于預(yù)期標(biāo)志，如果全部相等凫岖，則以原子方式將該引用和該標(biāo)志的值設(shè)置為給定的更新值江咳。

??????? 2 循環(huán)時間長開銷大

??????? 自旋CAS（也就是不成功就一直循環(huán)執(zhí)行直到成功）如果長時間不成功，會給CPU帶來非常大的執(zhí)行開銷哥放。 如果JVM能支持處理器提供的pause指令那么效率會有一定的提升歼指，pause指令有兩個作用，第一它可以延遲流水線執(zhí)行指令（de-pipeline）,使CPU不會消耗過多的執(zhí)行資源甥雕，延遲的時間取決于具體實現(xiàn)的版本踩身，在一些處理器上延遲時間是零。第二它可以避免在退出循環(huán)的時候因內(nèi)存順序沖突（memory order violation）而引起CPU流水線被清空（CPU pipeline flush）社露，從而提高CPU的執(zhí)行效率挟阻。

??????? 3 只能保證一個共享變量的原子操作

??????? CAS 只對單個共享變量有效，當(dāng)操作涉及跨多個共享變量時 CAS 無效峭弟。但是從 JDK 1.5開始附鸽，提供了AtomicReference類來保證引用對象之間的原子性，你可以把多個變量放在一個對象里來進行 CAS 操作.所以我們可以使用鎖或者利用AtomicReference類把多個共享變量合并成一個共享變量來操作瞒瘸。

CAS與synchronized的使用情景

??????? 簡單的來說CAS適用于寫比較少的情況下（多讀場景坷备，沖突一般較少），synchronized適用于寫比較多的情況下（多寫場景挨务，沖突一般較多）

??????? 對于資源競爭較少（線程沖突較輕）的情況击你，使用synchronized同步鎖進行線程阻塞和喚醒切換以及用戶態(tài)內(nèi)核態(tài)間的切換操作額外浪費消耗cpu資源玉组；而CAS基于硬件實現(xiàn)谎柄，不需要進入內(nèi)核丁侄，不需要切換線程，操作自旋幾率較少朝巫，因此可以獲得更高的性能鸿摇。

??????? 對于資源競爭嚴(yán)重（線程沖突嚴(yán)重）的情況，CAS自旋的概率會比較大劈猿，從而浪費更多的CPU資源拙吉，效率低于synchronized。

??????? 補充： Java并發(fā)編程這個領(lǐng)域中synchronized關(guān)鍵字一直都是元老級的角色揪荣，很久之前很多人都會稱它為 “重量級鎖” 筷黔。但是，在JavaSE 1.6之后進行了主要包括為了減少獲得鎖和釋放鎖帶來的性能消耗而引入的 偏向鎖 和 輕量級鎖 以及其它各種優(yōu)化之后變得在某些情況下并不是那么重了仗颈。synchronized的底層實現(xiàn)主要依靠 Lock-Free 的隊列佛舱，基本思路是 自旋后阻塞，競爭切換后繼續(xù)競爭鎖挨决，稍微犧牲了公平性请祖，但獲得了高吞吐量。在線程沖突較少的情況下脖祈，可以獲得和CAS類似的性能肆捕；而線程沖突嚴(yán)重的情況下，性能遠(yuǎn)高于CAS盖高。

104.hashmap為何是線程不安全的慎陵？線程不安全有哪些表現(xiàn)？

??????? HashMap在put的時候喻奥，插入的元素超過了容量（由負(fù)載因子決定）的范圍就會觸發(fā)擴容操作席纽，就是rehash，這個會重新將原數(shù)組的內(nèi)容重新hash到新的擴容數(shù)組中映凳，在多線程的環(huán)境下胆筒，存在同時其他的元素也在進行put操作，如果hash值相同诈豌，可能出現(xiàn)同時在同一數(shù)組下用鏈表表示仆救，造成閉環(huán)，導(dǎo)致在get時會出現(xiàn)死循環(huán)矫渔，所以HashMap是線程不安全的彤蔽。

??????? 第一，如果多個線程同時使用put方法添加元素庙洼。假設(shè)正好存在兩個put的key發(fā)生了碰撞(hash值一樣)顿痪，那么根據(jù)HashMap的實現(xiàn)镊辕，這兩個key會添加到數(shù)組的同一個位置，這樣最終就會發(fā)生其中一個線程的put的數(shù)據(jù)被覆蓋蚁袭。

??????? 第二征懈，如果多個線程同時檢測到元素個數(shù)超過數(shù)組大小*loadFactor。

??????? 這樣會發(fā)生多個線程同時對hash數(shù)組進行擴容揩悄，都在重新計算元素位置以及復(fù)制數(shù)據(jù)卖哎，但是最終只有一個線程擴容后的數(shù)組會賦給table，也就是說其他線程的都會丟失删性，并且各自線程put的數(shù)據(jù)也丟失亏娜。且會引起死循環(huán)的錯誤。

105.數(shù)據(jù)庫引擎及比較

ISAM：ISAM執(zhí)行讀取操作的速度很快蹬挺，而且不占用大量的內(nèi)存和存儲資源维贺。ISAM的兩個主要不足之處在于，它不支持事務(wù)處理巴帮，也不能夠容錯

InnoDB：支持事務(wù)處理溯泣，支持外鍵，支持崩潰修復(fù)能力和并發(fā)控制晰韵。如果需要對事務(wù)的完整性要求比較高（比如銀行）发乔，要求實現(xiàn)并發(fā)控制（比如售票），那選擇InnoDB有很大的優(yōu)勢雪猪。如果需要頻繁的更新栏尚、刪除操作的數(shù)據(jù)庫，也可以選擇InnoDB只恨，因為支持事務(wù)的提交（commit）和回滾（rollback）译仗。

MyISAM：插入數(shù)據(jù)快，空間和內(nèi)存使用比較低官觅。如果表主要是用于插入新記錄和讀出記錄纵菌，那么選擇MyISAM能實現(xiàn)處理高效率。如果應(yīng)用的完整性休涤、并發(fā)性要求比較低咱圆，也可以使用。

MEMORY：所有的數(shù)據(jù)都在內(nèi)存中功氨，數(shù)據(jù)的處理速度快序苏，但是安全性不高。如果需要很快的讀寫速度捷凄，對數(shù)據(jù)的安全性要求較低忱详，可以選擇MEMOEY。它對表的大小有要求跺涤，不能建立太大的表匈睁。所以监透，這類數(shù)據(jù)庫只使用在相對較小的數(shù)據(jù)庫表。

106.ConcurrentHashMap原理分析（1.7與1.8）-put和 get 需要執(zhí)行兩次Hash航唆？

??????? ConcurrentHashMap 與HashMap和Hashtable 最大的不同在于：put和 get 兩次Hash到達指定的HashEntry胀蛮，第一次hash到達Segment,第二次到達Segment里面的Entry,然后在遍歷entry鏈表

??????? 總結(jié)與思考

??????? 其實可以看出JDK1.8版本的ConcurrentHashMap的數(shù)據(jù)結(jié)構(gòu)已經(jīng)接近HashMap，相對而言佛点，ConcurrentHashMap只是增加了同步的操作來控制并發(fā)醇滥，從JDK1.7版本的ReentrantLock+Segment+HashEntry黎比，到JDK1.8版本中synchronized+CAS+HashEntry+紅黑樹,相對而言超营，總結(jié)如下思考

??????? JDK1.8的實現(xiàn)降低鎖的粒度，JDK1.7版本鎖的粒度是基于Segment的阅虫，包含多個HashEntry演闭，而JDK1.8鎖的粒度就是HashEntry（首節(jié)點）

??????? JDK1.8版本的數(shù)據(jù)結(jié)構(gòu)變得更加簡單，使得操作也更加清晰流暢颓帝，因為已經(jīng)使用synchronized來進行同步米碰，所以不需要分段鎖的概念，也就不需要Segment這種數(shù)據(jù)結(jié)構(gòu)了购城，由于粒度的降低吕座，實現(xiàn)的復(fù)雜度也增加了

??????? JDK1.8使用紅黑樹來優(yōu)化鏈表，基于長度很長的鏈表的遍歷是一個很漫長的過程瘪板，而紅黑樹的遍歷效率是很快的吴趴，代替一定閾值的鏈表，這樣形成一個最佳拍檔

??????? JDK1.8為什么使用內(nèi)置鎖synchronized來代替重入鎖ReentrantLock侮攀，我覺得有以下幾點：

??????? （1）因為粒度降低了锣枝，在相對而言的低粒度加鎖方式，synchronized并不比ReentrantLock差兰英，在粗粒度加鎖中ReentrantLock可能通過Condition來控制各個低粒度的邊界撇叁，更加的靈活，而在低粒度中畦贸，Condition的優(yōu)勢就沒有了

??????? （2）JVM的開發(fā)團隊從來都沒有放棄synchronized陨闹，而且基于JVM的synchronized優(yōu)化空間更大，使用內(nèi)嵌的關(guān)鍵字比使用API更加自然

??????? （3）在大量的數(shù)據(jù)操作下薄坏，對于JVM的內(nèi)存壓力趋厉，基于API的ReentrantLock會開銷更多的內(nèi)存，雖然不是瓶頸颤殴，但是也是一個選擇依據(jù)

107.ConcurrentHashMap實現(xiàn)原理

??????? HashMap ：先說HashMap觅廓，HashMap是線程不安全的，在并發(fā)環(huán)境下涵但，可能會形成環(huán)狀鏈表（擴容時可能造成杈绸，具體原因自行百度google或查看源碼分析）帖蔓，導(dǎo)致get操作時，cpu空轉(zhuǎn)瞳脓，所以塑娇，在并發(fā)環(huán)境中使用HashMap是非常危險的。

??????? HashTable ： HashTable和HashMap的實現(xiàn)原理幾乎一樣劫侧，差別無非是1.HashTable不允許key和value為null埋酬；2.HashTable是線程安全的。但是HashTable線程安全的策略實現(xiàn)代價卻太大了烧栋，簡單粗暴写妥，get/put所有相關(guān)操作都是synchronized的，這相當(dāng)于給整個哈希表加了一把大鎖审姓，多線程訪問時候珍特，只要有一個線程訪問或操作該對象，那其他線程只能阻塞魔吐，相當(dāng)于將所有的操作串行化扎筒，在競爭激烈的并發(fā)場景中性能就會非常差。

??????? HashTable性能差主要是由于所有操作需要競爭同一把鎖酬姆，而如果容器中有多把鎖嗜桌，每一把鎖鎖一段數(shù)據(jù)，這樣在多線程訪問時不同段的數(shù)據(jù)時辞色，就不會存在鎖競爭了骨宠，這樣便可以有效地提高并發(fā)效率。這就是ConcurrentHashMap所采用的"分段鎖"思想淫僻。

??????? ConcurrentHashMap采用了非常精妙的"分段鎖"策略诱篷，ConcurrentHashMap的主干是個Segment數(shù)組。

??????? Segment繼承了ReentrantLock雳灵，所以它就是一種可重入鎖（ReentrantLock)棕所。在ConcurrentHashMap，一個Segment就是一個子哈希表悯辙，Segment里維護了一個HashEntry數(shù)組琳省，并發(fā)環(huán)境下，對于不同Segment的數(shù)據(jù)進行操作是不用考慮鎖競爭的躲撰。（就按默認(rèn)的ConcurrentLeve為16來講针贬，理論上就允許16個線程并發(fā)執(zhí)行，有木有很酷）

??????? 所以拢蛋，對于同一個Segment的操作才需考慮線程同步桦他，不同的Segment則無需考慮。

??????? Segment類似于HashMap谆棱，一個Segment維護著一個HashEntry數(shù)組

??????? 源碼：transient volatile HashEntry[] table; HashEntry是目前我們提到的最小的邏輯處理單元了快压。一個ConcurrentHashMap維護一個Segment數(shù)組圆仔，一個Segment維護一個HashEntry數(shù)組。

108.java加載器雙親委派模型

??????? 雙親委派模型的式作過程是：如果一個類加載器收到了類加載的請求蔫劣，它首先不會自己去嘗試加載這個類坪郭，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此脉幢，因此所有的加載請求最終都應(yīng)該傳送到頂層的啟動類加載器中歪沃，只有當(dāng)父加載器反饋自己無法完全這個加載請求時，子加載器才會嘗試自己去加載嫌松。

109.非遞歸且不用額外空間（不用棧）沪曙，如何遍歷二叉樹

??????? 要使用O(1)空間進行遍歷，最大的難點在于豆瘫，遍歷到子節(jié)點的時候怎樣重新返回到父節(jié)點（假設(shè)節(jié)點中沒有指向父節(jié)點的p指針）珊蟀，由于不能用棧作為輔助空間。為了解決這個問題外驱，Morris方法用到了線索二叉樹（threaded binary tree）的概念。在Morris方法中不需要為每個節(jié)點額外分配指針指向其前驅(qū)（predecessor）和后繼節(jié)點（successor）腻窒，只需要利用葉子節(jié)點中的左右空指針指向某種順序遍歷下的前驅(qū)節(jié)點或后繼節(jié)點就可以了昵宇。

110.HTTP瀏覽器輸入URL后發(fā)生了什么

??????? 1.DNS域名解析；

??????? 2.建立TCP連接儿子；

??????? 3.發(fā)送HTTP請求瓦哎；

??????? 4.服務(wù)器處理請求；

??????? 5.返回響應(yīng)結(jié)果柔逼；

??????? 6.關(guān)閉TCP連接蒋譬；

??????? 7.瀏覽器解析HTML；

??????? 8.瀏覽器布局渲染愉适；