說說進程和線程的區(qū)別？進程是程序的一次執(zhí)行，是系統(tǒng)進行資源分配和調度的獨立單位，他的作用是是程序能夠并發(fā)執(zhí)行提高資源利用率和吞吐率。 由于進程是資源分配和調度的基本單位，因為進程的創(chuàng)建、銷毀、切換產生大量的時間和空間的開銷，進程的數量不能太多，而線程是比進程更小的能獨立運行的基本單位，他是進程的一個實體，可以減少程序并發(fā)執(zhí)行時的時間和空間開銷，使得操作系統(tǒng)具有更好的并發(fā)性。 線程基本不擁有系統(tǒng)資源，只有一些運行時必不可少的資源，比如程序計數器、寄存器和棧，進程則占有堆、棧。 知道synchronized原理嗎？synchronized是java提供的原子性內置鎖，這種內置的并且使用者看不到的鎖也被稱為監(jiān)視器鎖，使用synchronized之后，會在編譯之后在同步的代碼塊前后加上monitorenter和monitorexit字節(jié)碼指令，他依賴操作系統(tǒng)底層互斥鎖實現。他的作用主要就是實現原子性操作和解決共享變量的內存可見性問題。 執(zhí)行monitorenter指令時會嘗試獲取對象鎖，如果對象沒有被鎖定或者已經獲得了鎖，鎖的計數器 1。此時其他競爭鎖的線程則會進入等待隊列中。 執(zhí)行monitorexit指令時則會把計數器-1，當計數器值為0時，則鎖釋放，處于等待隊列中的線程再繼續(xù)競爭鎖。 synchronized是排它鎖，當一個線程獲得鎖之后，其他線程必須等待該線程釋放鎖后才能獲得鎖，而且由于Java中的線程和操作系統(tǒng)原生線程是一一對應的，線程被阻塞或者喚醒時時會從用戶態(tài)切換到內核態(tài)，這種轉換非常消耗性能。 從內存語義來說，加鎖的過程會清除工作內存中的共享變量，再從主內存讀取，而釋放鎖的過程則是將工作內存中的共享變量寫回主內存。 實際上大部分時候我認為說到monitorenter就行了，但是為了更清楚的描述，還是再具體一點。 如果再深入到源碼來說，synchronized實際上有兩個隊列waitSet和entryList。
那鎖的優(yōu)化機制了解嗎？從JDK1.6版本之后，synchronized本身也在不斷優(yōu)化鎖的機制，有些情況下他并不會是一個很重量級的鎖了。優(yōu)化機制包括自適應鎖、自旋鎖、鎖消除、鎖粗化、輕量級鎖和偏向鎖。 鎖的狀態(tài)從低到高依次為無鎖->偏向鎖->輕量級鎖->重量級鎖，升級的過程就是從低到高，降級在一定條件也是有可能發(fā)生的。 自旋鎖：由于大部分時候，鎖被占用的時間很短，共享變量的鎖定時間也很短，所有沒有必要掛起線程，用戶態(tài)和內核態(tài)的來回上下文切換嚴重影響性能。自旋的概念就是讓線程執(zhí)行一個忙循環(huán)，可以理解為就是啥也不干，防止從用戶態(tài)轉入內核態(tài)，自旋鎖可以通過設置-XX: UseSpining來開啟，自旋的默認次數是10次，可以使用-XX:PreBlockSpin設置。 自適應鎖：自適應鎖就是自適應的自旋鎖，自旋的時間不是固定時間，而是由前一次在同一個鎖上的自旋時間和鎖的持有者狀態(tài)來決定。 鎖消除：鎖消除指的是JVM檢測到一些同步的代碼塊，完全不存在數據競爭的場景，也就是不需要加鎖，就會進行鎖消除。 鎖粗化：鎖粗化指的是有很多操作都是對同一個對象進行加鎖，就會把鎖的同步范圍擴展到整個操作序列之外。 偏向鎖：當線程訪問同步塊獲取鎖時，會在對象頭和棧幀中的鎖記錄里存儲偏向鎖的線程ID，之后這個線程再次進入同步塊時都不需要CAS來加鎖和解鎖了，偏向鎖會永遠偏向第一個獲得鎖的線程，如果后續(xù)沒有其他線程獲得過這個鎖，持有鎖的線程就永遠不需要進行同步，反之，當有其他線程競爭偏向鎖時，持有偏向鎖的線程就會釋放偏向鎖?？梢杂眠^設置-XX: UseBiasedLocking開啟偏向鎖。 輕量級鎖：JVM的對象的對象頭中包含有一些鎖的標志位，代碼進入同步塊的時候，JVM將會使用CAS方式來嘗試獲取鎖，如果更新成功則會把對象頭中的狀態(tài)位標記為輕量級鎖，如果更新失敗，當前線程就嘗試自旋來獲得鎖。 整個鎖升級的過程非常復雜，我盡力去除一些無用的環(huán)節(jié)，簡單來描述整個升級的機制。 簡單點說，偏向鎖就是通過對象頭的偏向線程ID來對比，甚至都不需要CAS了，而輕量級鎖主要就是通過CAS修改對象頭鎖記錄和自旋來實現，重量級鎖則是除了擁有鎖的線程其他全部阻塞。 那對象頭具體都包含哪些內容？在我們常用的Hotspot虛擬機中，對象在內存中布局實際包含3個部分：
而對象頭包含兩部分內容，Mark Word中的內容會隨著鎖標志位而發(fā)生變化，所以只說存儲結構就好了。
對于加鎖，那再說下ReentrantLock原理？他和synchronized有什么區(qū)別？相比于synchronized，ReentrantLock需要顯式的獲取鎖和釋放鎖，相對現在基本都是用JDK7和JDK8的版本，ReentrantLock的效率和synchronized區(qū)別基本可以持平了。他們的主要區(qū)別有以下幾點：
ReentrantLock基于AQS(AbstractQueuedSynchronizer 抽象隊列同步器)實現。別說了，我知道問題了，AQS原理我來講。 AQS內部維護一個state狀態(tài)位，嘗試加鎖的時候通過CAS(CompareAndSwap)修改值，如果成功設置為1，并且把當前線程ID賦值，則代表加鎖成功，一旦獲取到鎖，其他的線程將會被阻塞進入阻塞隊列自旋，獲得鎖的線程釋放鎖的時候將會喚醒阻塞隊列中的線程，釋放鎖的時候則會把state重新置為0，同時當前線程ID置為空。 CAS的原理呢？CAS叫做CompareAndSwap，比較并交換，主要是通過處理器的指令來保證操作的原子性，它包含三個操作數：
當執(zhí)行CAS指令時，只有當V等于A時，才會用B去更新V的值，否則就不會執(zhí)行更新操作。 那么CAS有什么缺點嗎？CAS的缺點主要有3點： ABA問題：ABA的問題指的是在CAS更新的過程中，當讀取到的值是A，然后準備賦值的時候仍然是A，但是實際上有可能A的值被改成了B，然后又被改回了A，這個CAS更新的漏洞就叫做ABA。只是ABA的問題大部分場景下都不影響并發(fā)的最終效果。 Java中有AtomicStampedReference來解決這個問題，他加入了預期標志和更新后標志兩個字段，更新時不光檢查值，還要檢查當前的標志是否等于預期標志，全部相等的話才會更新。 循環(huán)時間長開銷大：自旋CAS的方式如果長時間不成功，會給CPU帶來很大的開銷。 只能保證一個共享變量的原子操作：只對一個共享變量操作可以保證原子性，但是多個則不行，多個可以通過AtomicReference來處理或者使用鎖synchronized實現。 好，說說HashMap原理吧？HashMap主要由數組和鏈表組成，他不是線程安全的。核心的點就是put插入數據的過程，get查詢數據以及擴容的方式。JDK1.7和1.8的主要區(qū)別在于頭插和尾插方式的修改，頭插容易導致HashMap鏈表死循環(huán)，并且1.8之后加入紅黑樹對性能有提升。 put插入數據流程 往map插入元素的時候首先通過對key hash然后與數組長度-1進行與運算((n-1)&hash)，都是2的次冪所以等同于取模，但是位運算的效率更高。找到數組中的位置之后，如果數組中沒有元素直接存入，反之則判斷key是否相同，key相同就覆蓋，否則就會插入到鏈表的尾部，如果鏈表的長度超過8，則會轉換成紅黑樹，最后判斷數組長度是否超過默認的長度*負載因子也就是12，超過則進行擴容。 get查詢數據 查詢數據相對來說就比較簡單了，首先計算出hash值，然后去數組查詢，是紅黑樹就去紅黑樹查，鏈表就遍歷鏈表查詢就可以了。 resize擴容過程 擴容的過程就是對key重新計算hash，然后把數據拷貝到新的數組。 那多線程環(huán)境怎么使用Map呢？ConcurrentHashmap了解過嗎？多線程環(huán)境可以使用Collections.synchronizedMap同步加鎖的方式，還可以使用HashTable，但是同步的方式顯然性能不達標，而ConurrentHashMap更適合高并發(fā)場景使用。 ConcurrentHashmap在JDK1.7和1.8的版本改動比較大，1.7使用Segment HashEntry分段鎖的方式實現，1.8則拋棄了Segment，改為使用CAS synchronized Node實現，同樣也加入了紅黑樹，避免鏈表過長導致性能的問題。 1.7分段鎖 從結構上說，1.7版本的ConcurrentHashMap采用分段鎖機制，里面包含一個Segment數組，Segment繼承與ReentrantLock，Segment則包含HashEntry的數組，HashEntry本身就是一個鏈表的結構，具有保存key、value的能力能指向下一個節(jié)點的指針。 實際上就是相當于每個Segment都是一個HashMap，默認的Segment長度是16，也就是支持16個線程的并發(fā)寫，Segment之間相互不會受到影響。 put流程 其實發(fā)現整個流程和HashMap非常類似，只不過是先定位到具體的Segment，然后通過ReentrantLock去操作而已，后面的流程我就簡化了，因為和HashMap基本上是一樣的。
get流程 get也很簡單，key通過hash定位到segment，再遍歷鏈表定位到具體的元素上，需要注意的是value是volatile的，所以get是不需要加鎖的。 1.8CAS synchronized 1.8拋棄分段鎖，轉為用CAS synchronized來實現，同樣HashEntry改為Node，也加入了紅黑樹的實現。主要還是看put的流程。 put流程
get查詢 get很簡單，通過key計算hash，如果key hash相同就返回，如果是紅黑樹按照紅黑樹獲取，都不是就遍歷鏈表獲取。 volatile原理知道嗎？相比synchronized的加鎖方式來解決共享變量的內存可見性問題，volatile就是更輕量的選擇，他沒有上下文切換的額外開銷成本。使用volatile聲明的變量，可以確保值被更新的時候對其他線程立刻可見。volatile使用內存屏障來保證不會發(fā)生指令重排，解決了內存可見性的問題。 我們知道，線程都是從主內存中讀取共享變量到工作內存來操作，完成之后再把結果寫會主內存，但是這樣就會帶來可見性問題。舉個例子，假設現在我們是兩級緩存的雙核CPU架構，包含L1、L2兩級緩存。
那么，如果X變量用volatile修飾的話，當線程A再次讀取變量X的話，CPU就會根據緩存一致性協(xié)議強制線程A重新從主內存加載最新的值到自己的工作內存，而不是直接用緩存中的值。 再來說內存屏障的問題，volatile修飾之后會加入不同的內存屏障來保證可見性的問題能正確執(zhí)行。這里寫的屏障基于書中提供的內容，但是實際上由于CPU架構不同，重排序的策略不同，提供的內存屏障也不一樣，比如x86平臺上，只有StoreLoad一種內存屏障。
那么說說你對JMM內存模型的理解？為什么需要JMM？本身隨著CPU和內存的發(fā)展速度差異的問題，導致CPU的速度遠快于內存，所以現在的CPU加入了高速緩存，高速緩存一般可以分為L1、L2、L3三級緩存?；谏厦娴睦游覀冎懒诉@導致了緩存一致性的問題，所以加入了緩存一致性協(xié)議，同時導致了內存可見性的問題，而編譯器和CPU的重排序導致了原子性和有序性的問題，JMM內存模型正是對多線程操作下的一系列規(guī)范約束，因為不可能讓陳雇員的代碼去兼容所有的CPU，通過JMM我們才屏蔽了不同硬件和操作系統(tǒng)內存的訪問差異，這樣保證了Java程序在不同的平臺下達到一致的內存訪問效果，同時也是保證在高效并發(fā)的時候程序能夠正確執(zhí)行。
happen-before規(guī)則 雖然指令重排提高了并發(fā)的性能，但是Java虛擬機會對指令重排做出一些規(guī)則限制，并不能讓所有的指令都隨意的改變執(zhí)行位置，主要有以下幾點：
說了半天，到底工作內存和主內存是什么？主內存可以認為就是物理內存，Java內存模型中實際就是虛擬機內存的一部分。而工作內存就是CPU緩存，他有可能是寄存器也有可能是L1\L2\L3緩存，都是有可能的。 說說ThreadLocal原理？ThreadLocal可以理解為線程本地變量，他會在每個線程都創(chuàng)建一個副本，那么在線程之間訪問內部副本變量就行了，做到了線程之間互相隔離，相比于synchronized的做法是用空間來換時間。 ThreadLocal有一個靜態(tài)內部類ThreadLocalMap，ThreadLocalMap又包含了一個Entry數組，Entry本身是一個弱引用，他的key是指向ThreadLocal的弱引用，Entry具備了保存key value鍵值對的能力。 弱引用的目的是為了防止內存泄露，如果是強引用那么ThreadLocal對象除非線程結束否則始終無法被回收，弱引用則會在下一次GC的時候被回收。 但是這樣還是會存在內存泄露的問題，假如key和ThreadLocal對象被回收之后，entry中就存在key為null，但是value有值的entry對象，但是永遠沒辦法被訪問到，同樣除非線程結束運行。 但是只要ThreadLocal使用恰當，在使用完之后調用remove方法刪除Entry對象，實際上是不會出現這個問題的。 那引用類型有哪些？有什么區(qū)別？引用類型主要分為強軟弱虛四種：
線程池原理知道嗎？首先線程池有幾個核心的參數概念：
當提交一個新任務到線程池時，具體的執(zhí)行流程如下：
拒絕策略有哪些？主要有4種拒絕策略：
最后感謝大家看到這里，文章有不足，歡迎大家指出；如果你覺得寫得不錯，那就給我一個贊吧。 也歡迎大家關注我的公眾號：程序員麥冬，每天更新行業(yè)資訊！ 來源：https://www./content-1-758651.html |
|
|
