【Java】面試總結&面經學習記錄

此系列博客供自己復習所用，如有錯誤還忘指出

一、Java同步機制

參考鏈接：https://www.cnblogs.com/zeroingToOne/p/9554560.html

1.1 Java做到執行緒同步方法

在需要同步的方法的方法簽名中加上synchronized關鍵字（鎖方法）
使用synchronized關鍵字對需要進行同步的代碼塊進行同步 (鎖代碼塊)
使用java.util.concurrent.lock包中Lock物件（JDK1.8）—JDK 1.5出現
使用volatile關鍵字(不能替代synchronized)

a. volatile關鍵字為域變數的訪問提供了一種免鎖機制
b. 使用volatile修飾域相當于告訴虛擬機該域可能會被其他執行緒更新
c. 因此每次使用該域就要重新計算，而不是使用暫存器中的值
d. volatile不會提供任何原子操作（因此不能替換synchronized），它也不能用來修飾final型別的變數

1.2 synchronized使用時需要注意的一些地方：

被synchronized關鍵字修飾的代碼塊在被執行緒執行之前，首先要拿到被同步物件的鎖，并且一個物件僅僅是只有一個鎖，比如上面被synchronized代碼，首先那個方法需要拿到當前物件的鎖，如果當前的鎖已經被其它執行緒拿走了，那么還沒搶到鎖的執行緒將從可運行狀態轉變為阻塞狀態，只有當拿到鎖的執行緒執行完同步塊的代碼后，就釋放鎖，讓給別的執行緒的、這樣就可以保證資料的完整性！

1.3 關于Lock物件和synchronized關鍵字的選擇：

（1）最好兩個都不用，使用一種java.util.concurrent包提供的機制，能夠幫助用戶處理所有與鎖相關的代碼，？？
（2）如果synchronized關鍵字能夠滿足用戶的需求，就用synchronized，他能簡化代碼，
（3）如果需要使用更高級的功能，就用ReentrantLock類，此時要注意及時釋放鎖，否則會出現死鎖，通常在finally中釋放鎖，

1.4 volatile與synchronized的區別：

參考鏈接：https://blog.csdn.net/suifeng3051/article/details/52611233

全面了解推薦鏈接：https://blog.csdn.net/suifeng3051/article/details/52611310 JMMJava記憶體模型

volatile本質是在告訴jvm當前變數在暫存器（作業記憶體）中的值是不確定的，需要從主存中讀取； synchronized則是鎖定當前變數，只有當前執行緒可以訪問該變數，其他執行緒被阻塞住，
volatile僅能使用在變數級別；synchronized則可以使用在變數、方法、和類級別的
volatile僅能實作變數的修改可見性，不能保證原子性；而synchronized則可以保證變數的修改可見性和原子性
volatile不會造成執行緒的阻塞；synchronized可能會造成執行緒的阻塞，
volatile標記的變數不會被編譯器優化；synchronized標記的變數可以被編譯器優化

volatile就是基于記憶體屏障實作

1.5 happens-before

參考鏈接：https://www.cnblogs.com/chenssy/p/6393321.html

從jdk5開始，java使用新的JSR-133記憶體模型，基于happens-before的概念來闡述操作之間的記憶體可見性，

在JMM中，如果一個操作的執行結果需要對另一個操作可見，那么這兩個操作之間必須存在happens-before關系，這兩個操作即可以在同一個執行緒，也可以在不同的執行緒中，

happens-before原則定義

如果一個操作happens-before另一個操作，那么第一個操作的結果將對第二個操作可見，而且第一個操作的執行順序排在第二個操作之前
兩個操作之間存在happens-before關系，并不意味著一定要按照happens-before原則制定的順序來執行，如果重排序之后的執行結果與按照happens-before關系來執行的結果一致，那么這種重排序并不非法，

happens-before原則規則

程式次序規則：一個執行緒內，按照代碼順序，書寫在前面的操作先行發生于書寫在后面的操作；
鎖定規則：一個unLock操作先行發生于后面對同一個鎖的lock操作；
volatile變數規則：對一個變數的寫操作先行發生于后面對這個變數的讀操作；
傳遞規則：如果操作A先行發生于操作B，而操作B又先行發生于操作C，則可以得出操作A先行發生于操作C；
執行緒啟動規則：Thread物件的start()方法先行發生于此執行緒的每個一個動作；
執行緒中斷規則：對執行緒interrupt()方法的呼叫先行發生于被中斷執行緒的代碼檢測到中斷事件的發生；
執行緒終結規則：執行緒中所有的操作都先行發生于執行緒的終止檢測，我們可以通過Thread.join()方法結束、Thread.isAlive()的回傳值手段檢測到執行緒已經終止執行；
物件終結規則：一個物件的初始化完成先行發生于他的finalize()方法的開始；

happens-before與JMM的關系圖（摘自《Java并發編程的藝術》）

happens-before

二、HashMap (Java 8系列)

參考鏈接：https://tech.meituan.com/2016/06/24/java-hashmap.html

2.1 Map家族

HashMap：根據鍵的hashCode值存盤資料，非執行緒安全，可以用synchronizedMap方法使HashMap具有執行緒安全的能力，或者使用ConcurrentHashMap
Hashtable：遺留類，執行緒安全，但是不建議使用
LinkedHashMap：保存了記錄的插入順序
TreeMap：實作了SortedMap介面，能夠把它保存的記錄根據鍵排序，默認是升序排序

2.2 HashMap存盤結構

陣列+鏈表+紅黑樹

當put一個鍵值對時，首先獲取key值的hashCode值，在通過hash演算法（高位運算和取模運算）來定位該剪值對對對應的陣列下標，然后再找鏈表或紅黑樹值（具體見下面），

在理解Hash和擴容流程之前，我們得先了解下HashMap的幾個欄位，從HashMap的默認建構式原始碼可知，建構式就是對下面幾個欄位進行初始化，原始碼如下：

int threshold;             // 所能容納的key-value對極限 
final float loadFactor;    // 負載因子
int modCount;  
int size;

Load factor為負載因子(默認值是0.75)

threshold是HashMap所能容納的最大資料量的Node(鍵值對)個數，threshold = length * Load factor，也就是說，在陣列定義好長度之后，負載因子越大，所能容納的鍵值對個數越多，

modCount欄位主要用來記錄HashMap內部結構發生變化的次數

size：HashMap中實際存在的鍵值對數量

哈希桶陣列table的長度length大小必須為2的n次方(一定是合數)，這是一種非常規的設計，常規的設計是把桶的大小設計為素數，HashMap采用這種非常規設計，主要是為了在取模和擴容時做優化，同時為了減少沖突，HashMap定位哈希桶索引位置時，也加入了高位參與運算的程序，

2.3 HashMap的put方法

（具體見鏈接）

三、ArrayList和LinkedList區別

參考鏈接：https://blog.csdn.net/eson_15/article/details/51145788

1. List概括

2. ArrayList和LinkedList區別

ArrayList實作了基于動態陣列的資料結構，而LinkedList是基于鏈表的資料結構（雙向鏈表，它同樣可以被當做堆疊，佇列或雙端佇列來使用）；
對于隨機訪問get和set，ArrayList要優于LinkedList，因為LinkedList要移動指標；
對于添加和洗掉操作add和remove，一般大家都會說LinkedList要比ArrayList快，因為ArrayList要移動資料，但是實際情況并非這樣，對于添加或洗掉，LinkedList和ArrayList并不能明確說明誰快誰慢；

從原始碼可以看出，ArrayList想要get(int index)元素時，直接回傳index位置上的元素，而LinkedList需要通過for回圈進行查找，雖然LinkedList已經在查找方法上做了優化，比如index < size / 2，則從左邊開始查找，反之從右邊開始查找，但是還是比ArrayList要慢，這點是毋庸置疑的，
ArrayList想要在指定位置插入或洗掉元素時，主要耗時的是System.arraycopy動作，會移動index后面所有的元素；LinkedList主耗時的是要先通過for回圈找到index，然后直接插入或洗掉，(這就導致了兩者并非一定誰快誰慢)

所以當插入的資料量很小時，兩者區別不太大，當插入的資料量大時，大約在容量的1/10之前，LinkedList會優于ArrayList，在其后就劣與ArrayList，且越靠近后面越差，所以個人覺得，一般首選用ArrayList，由于LinkedList可以實作堆疊、佇列以及雙端佇列等資料結構，所以當特定需要時候，使用LinkedList，當然咯，資料量小的時候，兩者差不多，視具體情況去選擇使用；當資料量大的時候，如果只需要在靠前的部分插入或洗掉資料，那也可以選用LinkedList，反之選擇ArrayList反而效率更高，

四、JVM基礎

參考鏈接：https://www.cnblogs.com/aspirant/p/6841955.html

1. 什么是JVM

jvm是一種用于計算設備的規范，它是一個虛構出來的機器，是通過在實際的計算機上仿真模擬各種功能實作的，
jvm包含一套位元組碼指令集，一組暫存器，一個堆疊，一個垃圾回收堆和一個存盤方法域，
VM屏蔽了與具體作業系統平臺相關的資訊，使Java程式只需生成在Java虛擬機上運行的目標代碼（位元組碼）,就可以在多種平臺上不加修改地運行，

2. JVM原理

java編譯器只要面向jvm，生成jvm能理解的位元組碼檔案，java源檔案經編譯成位元組碼程式，通過jvm將每條指令翻譯成不同的機器碼，通過特定平臺運行，(JIT即時編譯器Just-In-Time Compiler)

3. JVM執行程式的程序

加載class檔案
管理并分配記憶體
執行垃圾收集

4. JVM生命周期

JVM實體對應了一個獨立運行的Java程式，它是行程級別
- 啟動，啟動一個Java程式時，一個JVM實體就產生了
- 運行，main()作為該程式初始執行緒的起點，任何其他執行緒均由該執行緒啟動，JVM內部有兩種執行緒：守護執行緒和非守護執行緒，main()屬于非守護執行緒，守護執行緒通常由JVM自己使用，java程式也可以表明自己創建的執行緒是守護執行緒
- 消亡，當程式中的所有非守護執行緒都終止時，JVM才退出；若安全管理器允許，程式也可以使用Runtime類或者System.exit()來退出
JVM執行引擎實體則對應了屬于用戶運行程式的執行緒，它是執行緒級別的

5. JVM記憶體模型

運行時資料區，即jvm記憶體結構如下圖，

運行是資料區存盤了哪些資料
- 程式計數器（PC暫存器）
每個執行緒都需要有自己獨立的程式計數器,程式計數器是每個執行緒所私有的，由于程式計數器中存盤的資料所占空間的大小不會隨程式的執行而發生改變，因此，對于程式計數器是不會發生記憶體溢位現象(OutOfMemory)的，
- Java堆疊
Java堆疊中存放的是一個個的堆疊幀，每個堆疊幀對應一個被呼叫的方法，在堆疊幀中包括區域變數表(Local Variables)、運算元堆疊(Operand Stack)、指向當前方法所屬的類的運行時常量池（運行時常量池的概念在方法區部分會談到）的參考(Reference to runtime constant pool)、**方法回傳地址(Return Address)**和一些額外的附加資訊
- 本地方法堆疊
本地方法堆疊與Java堆疊的作用和原理非常相似，區別只不過是Java堆疊是為執行Java方法服務的，而本地方法堆疊則是為執行本地方法（Native Method）服務的
- 堆
Java中的堆是用來存盤物件本身的以及陣列（陣列參考是存放在Java堆疊中的），堆是被所有執行緒共享的，在JVM中只有一個堆，
- 方法區
與堆一樣，是被執行緒共享的區域，在方法區中，存盤了每個類的資訊（包括類的名稱、方法資訊、欄位資訊）、靜態變數、常量以及編譯器編譯后的代碼等，

五、JVM的垃圾回識訓制

參考鏈接：https://www.cnblogs.com/aspirant/p/8662690.html

1. 哪些記憶體需要回收

JVM的記憶體結構包括五大區域：程式計數器、虛擬機堆疊、本地方法堆疊、堆區、方法區，其中程式計數器、虛擬機堆疊、本地方法堆疊3個區域隨執行緒而生、隨執行緒而滅，因此這幾個區域的記憶體分配和回收都具備確定性，就不需要過多考慮回收的問題，因為方法結束或者執行緒結束時，記憶體自然就跟隨著回收了，而Java堆區和方法區則不一樣、不一樣!(怎么不一樣說的朗朗上口)，這部分記憶體的分配和回收是動態的，正是垃圾收集器所需關注的部分，

垃圾收集器在對堆區和方法區進行回收前，首先要確定這些區域的物件哪些可以被回收，哪些暫時還不能回收，這就要用到判斷物件是否存活的演算法！

2. 判斷物件是否存活相關演算法

（1）參考計數演算法

演算法分析

在這種方法中，堆中每個物件實體都有一個參考計數，當一個物件被創建時，就將該物件實體分配給一個變數，該變數計數設定為1，當任何其它變數被賦值為這個物件的參考時，計數加1（a = b,則b參考的物件實體的計數器+1），但當一個物件實體的某個參考超過了生命周期或者被設定為一個新值時，物件實體的參考計數器減1，任何參考計數器為0的物件實體可以被當作垃圾收集，當一個物件實體被垃圾收集時，它參考的任何物件實體的參考計數器減1，

優缺點

優點：參考計數收集器可以很快的執行，交織在程式運行中，對程式需要不被長時間打斷的實時環境比較有利，
缺點：無法檢測出回圈參考，如父物件有一個對子物件的參考，子物件反過來參考父物件，這樣，他們的參考計數永遠不可能為0，

（2）可達性分析演算法

演算法分析

可達性分析演算法是從離散數學中的圖論引入的，程式把所有的參考關系看作一張圖，從一個節點GC ROOT開始，尋找對應的參考節點，找到這個節點以后，繼續尋找這個節點的參考節點，當所有的參考節點尋找完畢之后，剩余的節點則被認為是沒有被參考到的節點，即無用的節點，無用的節點將會被判定為是可回收的物件，

在Java語言中，可作為GC Roots的物件包括下面幾種：

虛擬機堆疊中參考的物件（堆疊幀中的本地變數表）
方法區中類靜態屬性參考的物件
方法區中常量參考的物件
本地方法堆疊中JNI（Native方法）參考的物件

**現在問題來了，可達性分析演算法會不會出現物件間回圈參考問題呢？答案是肯定的，那就是不會出現物件間回圈參考問題，**GC Root在物件圖之外，是特別定義的“起點”，不可能被物件圖內的物件所參考，

3. 物件死亡（被回收）前的最后一次掙扎

即使在可達性分析演算法中不可達的物件，也并非是“非死不可”，這時候它們暫時處于“緩刑”階段，要真正宣告一個物件死亡，至少要經歷兩次標記程序，

第一次標記：如果物件在進行可達性分析后發現沒有與GC Roots相連接的參考鏈，那它將會被第一次標記；
第二次標記：第一次標記后接著會進行一次篩選，篩選的條件是此物件是否有必要執行finalize()方法，在finalize()方法中沒有重新與參考鏈建立關聯關系的，將被進行第二次標記，

第二次標記成功的物件將真的會被回收，如果物件在finalize()方法中重新與參考鏈建立了關聯關系，那么將會逃離本次回收，繼續存活，

4. Java參考

強參考

在程式代碼中普遍存在的，類似 Object obj = new Object() 這類參考，只要強參考還存在，垃圾收集器永遠不會回收掉被參考的物件，
軟參考(SoftReference)

用來描述一些還有用但并非必須的物件，對于軟參考關聯著的物件，在系統將要發生記憶體溢位例外之前，將會把這些物件列進回收范圍之中進行第二次回收，如果這次回收后還沒有足夠的記憶體，才會拋出記憶體溢位例外，
弱參考

也是用來描述非必需物件的，但是它的強度比軟參考更弱一些，被弱參考關聯的物件只能生存到下一次垃圾收集發生之前，當垃圾收集器作業時，無論當前記憶體是否足夠，都會回收掉只被弱參考關聯的物件，在JDK 1.2之后，提供了WeakReference類來實作弱參考，比如 threadlocal
虛參考

也叫幽靈參考或幻影參考，是最弱的一種參考關系，一個物件是否有虛參考的存在，完全不會對其生存時間構成影響，也無法通過虛參考來取得一個物件實體，它的作用是能在這個物件被收集器回收時收到一個系統通知，，在JDK 1.2之后，提供了PhantomReference類來實作虛參考，

5. 方法區如何判斷是否需要回收

主要回收內容為：廢棄常量和無用的類，對于廢棄常量也可通過參考的可達性來判斷，但是對于無用的類則需要同時滿足下面3個條件：

該類所有的實體都已經被回收，也就是Java堆中不存在該類的任何實體；
加載該類的ClassLoader已經被回收；
該類對應的java.lang.Class物件沒有在任何地方被參考，無法在任何地方通過反射訪問該類的方法，

6. 常見的垃圾收集演算法

（1）參考計數法（同上）

（2）標記-清除演算法（Mark-Sweep）

最基礎的垃圾回收演算法，最容易實作，思想也是最簡單的，

分為兩個階段：標記階段和清除階段，

標記階段的任務是標記出所有需要被回收的物件，清除階段就是回收被標記的物件所占用的空間，

標記-清除演算法采用從根集合（GC Roots）進行掃描，對存活的物件進行標記，標記完畢后，再掃描整個空間中未被標記的物件，進行回收，如下圖所示，

（3）復制演算法（Copying）

（明天接著看，，，）

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/255638.html

標籤：其他

上一篇：用opencv給彥女王生成一副蒙太奇畫像

下一篇：[系統安全] 十七.Windows PE病毒概念、分類及感染方式詳解

【Java】 面試總結&面經學習記錄（2.1更新）

【Java】 面試總結&面經學習記錄