《我想進大廠》之Java基礎奪命連環16問

說好了面試系列已經完結了,結果發現仍是真香,嗯,覺得我發現個人Java基礎都沒寫,因此這個就算做續集了,續集第一篇請各位收好。java

說說進程和線程的區別?

進程是程序的一次執行,是系統進行資源分配和調度的獨立單位,他的做用是是程序可以併發執行提升資源利用率和吞吐率。node

因爲進程是資源分配和調度的基本單位,由於進程的建立、銷燬、切換產生大量的時間和空間的開銷,進程的數量不能太多,而線程是比進程更小的能獨立運行的基本單位,他是進程的一個實體,能夠減小程序併發執行時的時間和空間開銷,使得操做系統具備更好的併發性。面試

線程基本不擁有系統資源,只有一些運行時必不可少的資源,好比程序計數器、寄存器和棧,進程則佔有堆、棧。數組

知道synchronized原理嗎?

synchronized是java提供的原子性內置鎖,這種內置的而且使用者看不到的鎖也被稱爲監視器鎖,使用synchronized以後,會在編譯以後在同步的代碼塊先後加上monitorenter和monitorexit字節碼指令,他依賴操做系統底層互斥鎖實現。他的做用主要就是實現原子性操做和解決共享變量的內存可見性問題。緩存

執行monitorenter指令時會嘗試獲取對象鎖,若是對象沒有被鎖定或者已經得到了鎖,鎖的計數器+1。此時其餘競爭鎖的線程則會進入等待隊列中。安全

執行monitorexit指令時則會把計數器-1,當計數器值爲0時,則鎖釋放,處於等待隊列中的線程再繼續競爭鎖。多線程

synchronized是排它鎖,當一個線程得到鎖以後,其餘線程必須等待該線程釋放鎖後才能得到鎖,並且因爲Java中的線程和操做系統原生線程是一一對應的,線程被阻塞或者喚醒時時會從用戶態切換到內核態,這種轉換很是消耗性能。架構

從內存語義來講,加鎖的過程會清除工做內存中的共享變量,再從主內存讀取,而釋放鎖的過程則是將工做內存中的共享變量寫回主內存。併發

實際上大部分時候我認爲說到monitorenter就好了,可是爲了更清楚的描述,仍是再具體一點app

若是再深刻到源碼來講,synchronized實際上有兩個隊列waitSet和entryList。

  1. 當多個線程進入同步代碼塊時,首先進入entryList
  2. 有一個線程獲取到monitor鎖後,就賦值給當前線程,而且計數器+1
  3. 若是線程調用wait方法,將釋放鎖,當前線程置爲null,計數器-1,同時進入waitSet等待被喚醒,調用notify或者notifyAll以後又會進入entryList競爭鎖
  4. 若是線程執行完畢,一樣釋放鎖,計數器-1,當前線程置爲null

那鎖的優化機制瞭解嗎?

從JDK1.6版本以後,synchronized自己也在不斷優化鎖的機制,有些狀況下他並不會是一個很重量級的鎖了。優化機制包括自適應鎖、自旋鎖、鎖消除、鎖粗化、輕量級鎖和偏向鎖。

鎖的狀態從低到高依次爲無鎖->偏向鎖->輕量級鎖->重量級鎖,升級的過程就是從低到高,降級在必定條件也是有可能發生的。

自旋鎖:因爲大部分時候,鎖被佔用的時間很短,共享變量的鎖定時間也很短,全部沒有必要掛起線程,用戶態和內核態的來回上下文切換嚴重影響性能。自旋的概念就是讓線程執行一個忙循環,能夠理解爲就是啥也不幹,防止從用戶態轉入內核態,自旋鎖能夠經過設置-XX:+UseSpining來開啓,自旋的默認次數是10次,可使用-XX:PreBlockSpin設置。

自適應鎖:自適應鎖就是自適應的自旋鎖,自旋的時間不是固定時間,而是由前一次在同一個鎖上的自旋時間和鎖的持有者狀態來決定。

鎖消除:鎖消除指的是JVM檢測到一些同步的代碼塊,徹底不存在數據競爭的場景,也就是不須要加鎖,就會進行鎖消除。

鎖粗化:鎖粗化指的是有不少操做都是對同一個對象進行加鎖,就會把鎖的同步範圍擴展到整個操做序列以外。

偏向鎖:當線程訪問同步塊獲取鎖時,會在對象頭和棧幀中的鎖記錄裏存儲偏向鎖的線程ID,以後這個線程再次進入同步塊時都不須要CAS來加鎖和解鎖了,偏向鎖會永遠偏向第一個得到鎖的線程,若是後續沒有其餘線程得到過這個鎖,持有鎖的線程就永遠不須要進行同步,反之,當有其餘線程競爭偏向鎖時,持有偏向鎖的線程就會釋放偏向鎖。能夠用過設置-XX:+UseBiasedLocking開啓偏向鎖。

輕量級鎖:JVM的對象的對象頭中包含有一些鎖的標誌位,代碼進入同步塊的時候,JVM將會使用CAS方式來嘗試獲取鎖,若是更新成功則會把對象頭中的狀態位標記爲輕量級鎖,若是更新失敗,當前線程就嘗試自旋來得到鎖。

整個鎖升級的過程很是複雜,我盡力去除一些無用的環節,簡單來描述整個升級的機制。

簡單點說,偏向鎖就是經過對象頭的偏向線程ID來對比,甚至都不須要CAS了,而輕量級鎖主要就是經過CAS修改對象頭鎖記錄和自旋來實現,重量級鎖則是除了擁有鎖的線程其餘所有阻塞。

那對象頭具體都包含哪些內容?

在咱們經常使用的Hotspot虛擬機中,對象在內存中佈局實際包含3個部分:

  1. 對象頭
  2. 實例數據
  3. 對齊填充

而對象頭包含兩部份內容,Mark Word中的內容會隨着鎖標誌位而發生變化,因此只說存儲結構就行了。

  1. 對象自身運行時所需的數據,也被稱爲Mark Word,也就是用於輕量級鎖和偏向鎖的關鍵點。具體的內容包含對象的hashcode、分代年齡、輕量級鎖指針、重量級鎖指針、GC標記、偏向鎖線程ID、偏向鎖時間戳。
  2. 存儲類型指針,也就是指向類的元數據的指針,經過這個指針才能肯定對象是屬於哪一個類的實例。

若是是數組的話,則還包含了數組的長度

對於加鎖,那再說下ReentrantLock原理?他和synchronized有什麼區別?

相比於synchronized,ReentrantLock須要顯式的獲取鎖和釋放鎖,相對如今基本都是用JDK7和JDK8的版本,ReentrantLock的效率和synchronized區別基本能夠持平了。他們的主要區別有如下幾點:

  1. 等待可中斷,當持有鎖的線程長時間不釋放鎖的時候,等待中的線程能夠選擇放棄等待,轉而處理其餘的任務。
  2. 公平鎖:synchronized和ReentrantLock默認都是非公平鎖,可是ReentrantLock能夠經過構造函數傳參改變。只不過使用公平鎖的話會致使性能急劇降低。
  3. 綁定多個條件:ReentrantLock能夠同時綁定多個Condition條件對象。

ReentrantLock基於AQS(AbstractQueuedSynchronizer 抽象隊列同步器)實現。別說了,我知道問題了,AQS原理我來說。

AQS內部維護一個state狀態位,嘗試加鎖的時候經過CAS(CompareAndSwap)修改值,若是成功設置爲1,而且把當前線程ID賦值,則表明加鎖成功,一旦獲取到鎖,其餘的線程將會被阻塞進入阻塞隊列自旋,得到鎖的線程釋放鎖的時候將會喚醒阻塞隊列中的線程,釋放鎖的時候則會把state從新置爲0,同時當前線程ID置爲空。

CAS的原理呢?

CAS叫作CompareAndSwap,比較並交換,主要是經過處理器的指令來保證操做的原子性,它包含三個操做數:

  1. 變量內存地址,V表示
  2. 舊的預期值,A表示
  3. 準備設置的新值,B表示

當執行CAS指令時,只有當V等於A時,纔會用B去更新V的值,不然就不會執行更新操做。

那麼CAS有什麼缺點嗎?

CAS的缺點主要有3點:

ABA問題:ABA的問題指的是在CAS更新的過程當中,當讀取到的值是A,而後準備賦值的時候仍然是A,可是實際上有可能A的值被改爲了B,而後又被改回了A,這個CAS更新的漏洞就叫作ABA。只是ABA的問題大部分場景下都不影響併發的最終效果。

Java中有AtomicStampedReference來解決這個問題,他加入了預期標誌和更新後標誌兩個字段,更新時不光檢查值,還要檢查當前的標誌是否等於預期標誌,所有相等的話纔會更新。

循環時間長開銷大:自旋CAS的方式若是長時間不成功,會給CPU帶來很大的開銷。

只能保證一個共享變量的原子操做:只對一個共享變量操做能夠保證原子性,可是多個則不行,多個能夠經過AtomicReference來處理或者使用鎖synchronized實現。

好,說說HashMap原理吧?

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,而後把數據拷貝到新的數組。

那多線程環境怎麼使用Map呢?ConcurrentHashmap瞭解過嗎?

多線程環境可使用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基本上是同樣的。

  1. 計算hash,定位到segment,segment若是是空就先初始化
  2. 使用ReentrantLock加鎖,若是獲取鎖失敗則嘗試自旋,自旋超過次數就阻塞獲取,保證必定獲取鎖成功
  3. 遍歷HashEntry,就是和HashMap同樣,數組中key和hash同樣就直接替換,不存在就再插入鏈表,鏈表一樣

get流程

get也很簡單,key經過hash定位到segment,再遍歷鏈表定位到具體的元素上,須要注意的是value是volatile的,因此get是不須要加鎖的。

1.8CAS+synchronized

1.8拋棄分段鎖,轉爲用CAS+synchronized來實現,一樣HashEntry改成Node,也加入了紅黑樹的實現。主要仍是看put的流程。

put流程

  1. 首先計算hash,遍歷node數組,若是node是空的話,就經過CAS+自旋的方式初始化
  2. 若是當前數組位置是空則直接經過CAS自旋寫入數據
  3. 若是hash==MOVED,說明須要擴容,執行擴容
  4. 若是都不知足,就使用synchronized寫入數據,寫入數據一樣判斷鏈表、紅黑樹,鏈表寫入和HashMap的方式同樣,key hash同樣就覆蓋,反之就尾插法,鏈表長度超過8就轉換成紅黑樹

get查詢

get很簡單,經過key計算hash,若是key hash相同就返回,若是是紅黑樹按照紅黑樹獲取,都不是就遍歷鏈表獲取。

volatile原理知道嗎?

相比synchronized的加鎖方式來解決共享變量的內存可見性問題,volatile就是更輕量的選擇,他沒有上下文切換的額外開銷成本。使用volatile聲明的變量,能夠確保值被更新的時候對其餘線程馬上可見。volatile使用內存屏障來保證不會發生指令重排,解決了內存可見性的問題。

咱們知道,線程都是從主內存中讀取共享變量到工做內存來操做,完成以後再把結果寫會主內存,可是這樣就會帶來可見性問題。舉個例子,假設如今咱們是兩級緩存的雙核CPU架構,包含L一、L2兩級緩存。

  1. 線程A首先獲取變量X的值,因爲最初兩級緩存都是空,因此直接從主內存中讀取X,假設X初始值爲0,線程A讀取以後把X值都修改成1,同時寫回主內存。這時候緩存和主內存的狀況以下圖。

  1. 線程B也一樣讀取變量X的值,因爲L2緩存已經有緩存X=1,因此直接從L2緩存讀取,以後線程B把X修改成2,同時寫回L2和主內存。這時候的X值入下圖所示。

    那麼線程A若是再想獲取變量X的值,由於L1緩存已經有x=1了,因此這時候變量內存不可見問題就產生了,B修改成2的值對A來講沒有感知。

    image-20201111171451466

那麼,若是X變量用volatile修飾的話,當線程A再次讀取變量X的話,CPU就會根據緩存一致性協議強制線程A從新從主內存加載最新的值到本身的工做內存,而不是直接用緩存中的值。

再來講內存屏障的問題,volatile修飾以後會加入不一樣的內存屏障來保證可見性的問題能正確執行。這裏寫的屏障基於書中提供的內容,可是實際上因爲CPU架構不一樣,重排序的策略不一樣,提供的內存屏障也不同,好比x86平臺上,只有StoreLoad一種內存屏障。

  1. StoreStore屏障,保證上面的普通寫不和volatile寫發生重排序
  2. StoreLoad屏障,保證volatile寫與後面可能的volatile讀寫不發生重排序
  3. LoadLoad屏障,禁止volatile讀與後面的普通讀重排序
  4. LoadStore屏障,禁止volatile讀和後面的普通寫重排序

那麼說說你對JMM內存模型的理解?爲何須要JMM?

自己隨着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虛擬機會對指令重排作出一些規則限制,並不能讓全部的指令都隨意的改變執行位置,主要有如下幾點:

  1. 單線程每一個操做,happen-before於該線程中任意後續操做
  2. volatile寫happen-before與後續對這個變量的讀
  3. synchronized解鎖happen-before後續對這個鎖的加鎖
  4. final變量的寫happen-before於final域對象的讀,happen-before後續對final變量的讀
  5. 傳遞性規則,A先於B,B先於C,那麼A必定先於C發生

說了半天,到底工做內存和主內存是什麼?

主內存能夠認爲就是物理內存,Java內存模型中實際就是虛擬機內存的一部分。而工做內存就是CPU緩存,他有多是寄存器也有多是L1\L2\L3緩存,都是有可能的。

說說ThreadLocal原理?

ThreadLocal能夠理解爲線程本地變量,他會在每一個線程都建立一個副本,那麼在線程之間訪問內部副本變量就好了,作到了線程之間互相隔離,相比於synchronized的作法是用空間來換時間。

ThreadLocal有一個靜態內部類ThreadLocalMap,ThreadLocalMap又包含了一個Entry數組,Entry自己是一個弱引用,他的key是指向ThreadLocal的弱引用,Entry具有了保存key value鍵值對的能力。

弱引用的目的是爲了防止內存泄露,若是是強引用那麼ThreadLocal對象除非線程結束不然始終沒法被回收,弱引用則會在下一次GC的時候被回收。

可是這樣仍是會存在內存泄露的問題,假如key和ThreadLocal對象被回收以後,entry中就存在key爲null,可是value有值的entry對象,可是永遠沒辦法被訪問到,一樣除非線程結束運行。

可是隻要ThreadLocal使用恰當,在使用完以後調用remove方法刪除Entry對象,其實是不會出現這個問題的。

那引用類型有哪些?有什麼區別?

引用類型主要分爲強軟弱虛四種:

  1. 強引用指的就是代碼中廣泛存在的賦值方式,好比A a = new A()這種。強引用關聯的對象,永遠不會被GC回收。
  2. 軟引用能夠用SoftReference來描述,指的是那些有用可是不是必需要的對象。系統在發生內存溢出前會對這類引用的對象進行回收。
  3. 弱引用能夠用WeakReference來描述,他的強度比軟引用更低一點,弱引用的對象下一次GC的時候必定會被回收,而無論內存是否足夠。
  4. 虛引用也被稱做幻影引用,是最弱的引用關係,能夠用PhantomReference來描述,他必須和ReferenceQueue一塊兒使用,一樣的當發生GC的時候,虛引用也會被回收。能夠用虛引用來管理堆外內存。

線程池原理知道嗎?

首先線程池有幾個核心的參數概念:

  1. 最大線程數maximumPoolSize
  2. 核心線程數corePoolSize
  3. 活躍時間keepAliveTime
  4. 阻塞隊列workQueue
  5. 拒絕策略RejectedExecutionHandler

當提交一個新任務到線程池時,具體的執行流程以下:

  1. 當咱們提交任務,線程池會根據corePoolSize大小建立若干任務數量線程執行任務
  2. 當任務的數量超過corePoolSize數量,後續的任務將會進入阻塞隊列阻塞排隊
  3. 當阻塞隊列也滿了以後,那麼將會繼續建立(maximumPoolSize-corePoolSize)個數量的線程來執行任務,若是任務處理完成,maximumPoolSize-corePoolSize額外建立的線程等待keepAliveTime以後被自動銷燬
  4. 若是達到maximumPoolSize,阻塞隊列仍是滿的狀態,那麼將根據不一樣的拒絕策略對應處理

拒絕策略有哪些?

主要有4種拒絕策略:

  1. AbortPolicy:直接丟棄任務,拋出異常,這是默認策略
  2. CallerRunsPolicy:只用調用者所在的線程來處理任務
  3. DiscardOldestPolicy:丟棄等待隊列中最近的任務,並執行當前任務
  4. DiscardPolicy:直接丟棄任務,也不拋出異常
相關文章
相關標籤/搜索