說好了面試系列已經完結了,結果發現仍是真香,嗯,覺得我發現個人Java基礎都沒寫,因此這個就算做續集了,續集第一篇請各位收好。java
進程是程序的一次執行,是系統進行資源分配和調度的獨立單位,他的做用是是程序可以併發執行提升資源利用率和吞吐率。node
因爲進程是資源分配和調度的基本單位,由於進程的建立、銷燬、切換產生大量的時間和空間的開銷,進程的數量不能太多,而線程是比進程更小的能獨立運行的基本單位,他是進程的一個實體,能夠減小程序併發執行時的時間和空間開銷,使得操做系統具備更好的併發性。面試
線程基本不擁有系統資源,只有一些運行時必不可少的資源,好比程序計數器、寄存器和棧,進程則佔有堆、棧。數組
synchronized是java提供的原子性內置鎖,這種內置的而且使用者看不到的鎖也被稱爲監視器鎖,使用synchronized以後,會在編譯以後在同步的代碼塊先後加上monitorenter和monitorexit字節碼指令,他依賴操做系統底層互斥鎖實現。他的做用主要就是實現原子性操做和解決共享變量的內存可見性問題。緩存
執行monitorenter指令時會嘗試獲取對象鎖,若是對象沒有被鎖定或者已經得到了鎖,鎖的計數器+1。此時其餘競爭鎖的線程則會進入等待隊列中。安全
執行monitorexit指令時則會把計數器-1,當計數器值爲0時,則鎖釋放,處於等待隊列中的線程再繼續競爭鎖。多線程
synchronized是排它鎖,當一個線程得到鎖以後,其餘線程必須等待該線程釋放鎖後才能得到鎖,並且因爲Java中的線程和操做系統原生線程是一一對應的,線程被阻塞或者喚醒時時會從用戶態切換到內核態,這種轉換很是消耗性能。架構
從內存語義來講,加鎖的過程會清除工做內存中的共享變量,再從主內存讀取,而釋放鎖的過程則是將工做內存中的共享變量寫回主內存。併發
實際上大部分時候我認爲說到monitorenter就好了,可是爲了更清楚的描述,仍是再具體一點。app
若是再深刻到源碼來講,synchronized實際上有兩個隊列waitSet和entryList。
從JDK1.6版本以後,synchronized自己也在不斷優化鎖的機制,有些狀況下他並不會是一個很重量級的鎖了。優化機制包括自適應鎖、自旋鎖、鎖消除、鎖粗化、輕量級鎖和偏向鎖。
鎖的狀態從低到高依次爲無鎖->偏向鎖->輕量級鎖->重量級鎖,升級的過程就是從低到高,降級在必定條件也是有可能發生的。
自旋鎖:因爲大部分時候,鎖被佔用的時間很短,共享變量的鎖定時間也很短,全部沒有必要掛起線程,用戶態和內核態的來回上下文切換嚴重影響性能。自旋的概念就是讓線程執行一個忙循環,能夠理解爲就是啥也不幹,防止從用戶態轉入內核態,自旋鎖能夠經過設置-XX:+UseSpining來開啓,自旋的默認次數是10次,可使用-XX:PreBlockSpin設置。
自適應鎖:自適應鎖就是自適應的自旋鎖,自旋的時間不是固定時間,而是由前一次在同一個鎖上的自旋時間和鎖的持有者狀態來決定。
鎖消除:鎖消除指的是JVM檢測到一些同步的代碼塊,徹底不存在數據競爭的場景,也就是不須要加鎖,就會進行鎖消除。
鎖粗化:鎖粗化指的是有不少操做都是對同一個對象進行加鎖,就會把鎖的同步範圍擴展到整個操做序列以外。
偏向鎖:當線程訪問同步塊獲取鎖時,會在對象頭和棧幀中的鎖記錄裏存儲偏向鎖的線程ID,以後這個線程再次進入同步塊時都不須要CAS來加鎖和解鎖了,偏向鎖會永遠偏向第一個得到鎖的線程,若是後續沒有其餘線程得到過這個鎖,持有鎖的線程就永遠不須要進行同步,反之,當有其餘線程競爭偏向鎖時,持有偏向鎖的線程就會釋放偏向鎖。能夠用過設置-XX:+UseBiasedLocking開啓偏向鎖。
輕量級鎖:JVM的對象的對象頭中包含有一些鎖的標誌位,代碼進入同步塊的時候,JVM將會使用CAS方式來嘗試獲取鎖,若是更新成功則會把對象頭中的狀態位標記爲輕量級鎖,若是更新失敗,當前線程就嘗試自旋來得到鎖。
整個鎖升級的過程很是複雜,我盡力去除一些無用的環節,簡單來描述整個升級的機制。
簡單點說,偏向鎖就是經過對象頭的偏向線程ID來對比,甚至都不須要CAS了,而輕量級鎖主要就是經過CAS修改對象頭鎖記錄和自旋來實現,重量級鎖則是除了擁有鎖的線程其餘所有阻塞。
在咱們經常使用的Hotspot虛擬機中,對象在內存中佈局實際包含3個部分:
而對象頭包含兩部份內容,Mark Word中的內容會隨着鎖標誌位而發生變化,因此只說存儲結構就行了。
若是是數組的話,則還包含了數組的長度
相比於synchronized,ReentrantLock須要顯式的獲取鎖和釋放鎖,相對如今基本都是用JDK7和JDK8的版本,ReentrantLock的效率和synchronized區別基本能夠持平了。他們的主要區別有如下幾點:
ReentrantLock基於AQS(AbstractQueuedSynchronizer 抽象隊列同步器)實現。別說了,我知道問題了,AQS原理我來說。
AQS內部維護一個state狀態位,嘗試加鎖的時候經過CAS(CompareAndSwap)修改值,若是成功設置爲1,而且把當前線程ID賦值,則表明加鎖成功,一旦獲取到鎖,其餘的線程將會被阻塞進入阻塞隊列自旋,得到鎖的線程釋放鎖的時候將會喚醒阻塞隊列中的線程,釋放鎖的時候則會把state從新置爲0,同時當前線程ID置爲空。
CAS叫作CompareAndSwap,比較並交換,主要是經過處理器的指令來保證操做的原子性,它包含三個操做數:
當執行CAS指令時,只有當V等於A時,纔會用B去更新V的值,不然就不會執行更新操做。
CAS的缺點主要有3點:
ABA問題:ABA的問題指的是在CAS更新的過程當中,當讀取到的值是A,而後準備賦值的時候仍然是A,可是實際上有可能A的值被改爲了B,而後又被改回了A,這個CAS更新的漏洞就叫作ABA。只是ABA的問題大部分場景下都不影響併發的最終效果。
Java中有AtomicStampedReference來解決這個問題,他加入了預期標誌和更新後標誌兩個字段,更新時不光檢查值,還要檢查當前的標誌是否等於預期標誌,所有相等的話纔會更新。
循環時間長開銷大:自旋CAS的方式若是長時間不成功,會給CPU帶來很大的開銷。
只能保證一個共享變量的原子操做:只對一個共享變量操做能夠保證原子性,可是多個則不行,多個能夠經過AtomicReference來處理或者使用鎖synchronized實現。
HashMap主要由數組和鏈表組成,他不是線程安全的。核心的點就是put插入數據的過程,get查詢數據以及擴容的方式。JDK1.7和1.8的主要區別在於頭插和尾插方式的修改,頭插容易致使HashMap鏈表死循環,而且1.8以後加入紅黑樹對性能有提高。
put插入數據流程
往map插入元素的時候首先經過對key hash而後與數組長度-1進行與運算((n-1)&hash),都是2的次冪因此等同於取模,可是位運算的效率更高。找到數組中的位置以後,若是數組中沒有元素直接存入,反之則判斷key是否相同,key相同就覆蓋,不然就會插入到鏈表的尾部,若是鏈表的長度超過8,則會轉換成紅黑樹,最後判斷數組長度是否超過默認的長度*負載因子也就是12,超過則進行擴容。
get查詢數據
查詢數據相對來講就比較簡單了,首先計算出hash值,而後去數組查詢,是紅黑樹就去紅黑樹查,鏈表就遍歷鏈表查詢就能夠了。
resize擴容過程
擴容的過程就是對key從新計算hash,而後把數據拷貝到新的數組。
多線程環境可使用Collections.synchronizedMap同步加鎖的方式,還可使用HashTable,可是同步的方式顯然性能不達標,而ConurrentHashMap更適合高併發場景使用。
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的能力能指向下一個節點的指針。
實際上就是至關於每一個Segment都是一個HashMap,默認的Segment長度是16,也就是支持16個線程的併發寫,Segment之間相互不會受到影響。
put流程
其實發現整個流程和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相同就返回,若是是紅黑樹按照紅黑樹獲取,都不是就遍歷鏈表獲取。
相比synchronized的加鎖方式來解決共享變量的內存可見性問題,volatile就是更輕量的選擇,他沒有上下文切換的額外開銷成本。使用volatile聲明的變量,能夠確保值被更新的時候對其餘線程馬上可見。volatile使用內存屏障來保證不會發生指令重排,解決了內存可見性的問題。
咱們知道,線程都是從主內存中讀取共享變量到工做內存來操做,完成以後再把結果寫會主內存,可是這樣就會帶來可見性問題。舉個例子,假設如今咱們是兩級緩存的雙核CPU架構,包含L一、L2兩級緩存。
那麼線程A若是再想獲取變量X的值,由於L1緩存已經有x=1了,因此這時候變量內存不可見問題就產生了,B修改成2的值對A來講沒有感知。
那麼,若是X變量用volatile修飾的話,當線程A再次讀取變量X的話,CPU就會根據緩存一致性協議強制線程A從新從主內存加載最新的值到本身的工做內存,而不是直接用緩存中的值。
再來講內存屏障的問題,volatile修飾以後會加入不一樣的內存屏障來保證可見性的問題能正確執行。這裏寫的屏障基於書中提供的內容,可是實際上因爲CPU架構不一樣,重排序的策略不一樣,提供的內存屏障也不同,好比x86平臺上,只有StoreLoad一種內存屏障。
自己隨着CPU和內存的發展速度差別的問題,致使CPU的速度遠快於內存,因此如今的CPU加入了高速緩存,高速緩存通常能夠分爲L一、L二、L3三級緩存。基於上面的例子咱們知道了這致使了緩存一致性的問題,因此加入了緩存一致性協議,同時致使了內存可見性的問題,而編譯器和CPU的重排序致使了原子性和有序性的問題,JMM內存模型正是對多線程操做下的一系列規範約束,由於不可能讓陳僱員的代碼去兼容全部的CPU,經過JMM咱們才屏蔽了不一樣硬件和操做系統內存的訪問差別,這樣保證了Java程序在不一樣的平臺下達到一致的內存訪問效果,同時也是保證在高效併發的時候程序可以正確執行。
原子性:Java內存模型經過read、load、assign、use、store、write來保證原子性操做,此外還有lock和unlock,直接對應着synchronized關鍵字的monitorenter和monitorexit字節碼指令。
可見性:可見性的問題在上面的回答已經說過,Java保證可見性能夠認爲經過volatile、synchronized、final來實現。
有序性:因爲處理器和編譯器的重排序致使的有序性問題,Java經過volatile、synchronized來保證。
happen-before規則
雖然指令重排提升了併發的性能,可是Java虛擬機會對指令重排作出一些規則限制,並不能讓全部的指令都隨意的改變執行位置,主要有如下幾點:
主內存能夠認爲就是物理內存,Java內存模型中實際就是虛擬機內存的一部分。而工做內存就是CPU緩存,他有多是寄存器也有多是L1\L2\L3緩存,都是有可能的。
ThreadLocal能夠理解爲線程本地變量,他會在每一個線程都建立一個副本,那麼在線程之間訪問內部副本變量就好了,作到了線程之間互相隔離,相比於synchronized的作法是用空間來換時間。
ThreadLocal有一個靜態內部類ThreadLocalMap,ThreadLocalMap又包含了一個Entry數組,Entry自己是一個弱引用,他的key是指向ThreadLocal的弱引用,Entry具有了保存key value鍵值對的能力。
弱引用的目的是爲了防止內存泄露,若是是強引用那麼ThreadLocal對象除非線程結束不然始終沒法被回收,弱引用則會在下一次GC的時候被回收。
可是這樣仍是會存在內存泄露的問題,假如key和ThreadLocal對象被回收以後,entry中就存在key爲null,可是value有值的entry對象,可是永遠沒辦法被訪問到,一樣除非線程結束運行。
可是隻要ThreadLocal使用恰當,在使用完以後調用remove方法刪除Entry對象,其實是不會出現這個問題的。
引用類型主要分爲強軟弱虛四種:
首先線程池有幾個核心的參數概念:
當提交一個新任務到線程池時,具體的執行流程以下:
主要有4種拒絕策略: