深入理解 Java 中的 final 關(guān)鍵字
關(guān)于final關(guān)鍵字也是筆者早期整理的一篇文章，內(nèi)容比較基礎(chǔ)，所以借著假期將文章迭代一些，聊一些final關(guān)鍵字中的一些比較有意思的技術(shù)點，希望對你有幫助。
一、final關(guān)鍵字的不可變性
1. 為什么String要用final關(guān)鍵字修飾
final可以保證構(gòu)造時的安全初始化，從而實現(xiàn)不受限制的并發(fā)訪問，查看String源碼可以看到無論是在類聲明還是存儲字符串的value成員變量，都通過final符加以修飾結(jié)合構(gòu)造時安全初始化：
public final class String
implements java.io.Serializable, Comparable<String>, CharSequence {
/** The value is used for character storage. */
private final char value[];
//......
//安全構(gòu)造，從而保證當(dāng)前string類不受限制的被安全訪問
public String(String original) {
this.value = original.value;
this.hash = original.hash;
}
}這也就是利用到final關(guān)鍵字的第一個關(guān)鍵特性——不可變性，在Java中一切皆為對象，字符串類型也是一樣，所有的字符串對象也都存放在堆內(nèi)存中，為了更好的做到解決堆內(nèi)存空間和字符串的復(fù)用，一旦字符串類型做好了聲明并完成字符串創(chuàng)建之后，這個字符串對象的對應(yīng)值就不可再修改了。
例如，我們通過下面這段代碼：
String str = new String("hello world");在完成該字符串對象的創(chuàng)建時，因為final對于value的修飾，其底層本質(zhì)上就是創(chuàng)建了一個hello world的original不可變字符串，然后再創(chuàng)建一個String對象，并將其value和hash值設(shè)置hello world以及hello world的hash值：
這一點我們查看String的源碼定義也可以知曉這一點，可以看到上述的動作本質(zhì)上就是將堆區(qū)的常量和我的字符串類進行關(guān)聯(lián)，后續(xù)對于代碼的各種修改操作，本質(zhì)上也都是在字符串常量池中創(chuàng)建新的字面量與字符串類進行關(guān)聯(lián)：
public String(String original) {
//將字符串常量復(fù)制給當(dāng)前字符串類
this.value = original.value;
//將字符串常量hash賦值給當(dāng)前字符串
this.hash = original.hash;
}通過上述的原因保證了字符串的不可變性，使得堆內(nèi)存中有了字符串常量池的概念，保證同一字符串可以復(fù)用，節(jié)約堆內(nèi)存的同時還提升了程序的性能。同時為了保證這些操作不可被開發(fā)者修改與破壞，對于字符串類，設(shè)計者也將該類通過final修飾，保證字符串類的不可變性不被使用者通過繼承等方式遭到破壞，避免了一些字符串操作的安全漏洞和線程安全問題。
2. 利用final關(guān)鍵字實現(xiàn)常量折疊
我們再來看一個例子，如下所示，可以看到不同變量聲明的字符串test都和數(shù)字1進行拼接，最終與test1字符串進行==判斷引用地址是否一致：
//字符串常量池
String str1 = "test1";
//字符串變量
final String constStr = "test";
String str2 = "test";
//字符串拼接
String concatenatedWithConst = constStr + 1;
String concatenatedWithVar = str2 + 1;
//判斷是否是同一個對象
System.out.println(str1 == concatenatedWithConst);
System.out.println(str1 == concatenatedWithVar);最終輸出結(jié)果如下，可以看到采用final修飾的test字符串和數(shù)字1進行拼接之后，和str1的引用一致是一致的：
true
false對應(yīng)的我們也給出上述代碼的字節(jié)碼，可以看到在JIT階段，對應(yīng)19行(將constStr和數(shù)字1拼接)，因為constStr的不可變性，JIT階段就會直接將其視為編譯時常量和1進行拼接運算，由此直接得出test1。由此concatenatedWithConst就和str1同時指向字符串常量test1所以輸出結(jié)果比對一致:
// access flags 0x9
public static main([Ljava/lang/String;)V
// parameter args
//......
//
L3
LINENUMBER 19 L3
//將字符串常量test1放到操作數(shù)棧
LDC "test1"
//將操作數(shù)棧上的test1存儲到局部變量concatenatedWithConst 中
ASTORE 4對應(yīng)我們也給出concatenatedWithVar生成的字節(jié)碼，可以看到其底層本質(zhì)上就是通過StringBuilder拿到字符串常量中的test和數(shù)值1進行拼接從而得到常量池中的test1，然后將當(dāng)前concatenatedWithVar的引用指向這個常量，因為concatenatedWithVar間接的指向test1字符串，所以和str1的比對結(jié)果就不一致了：
L4
//初始化StringBuilder
LINENUMBER 20 L4
NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder.<init> ()V
//將第三個變量也就是我們的str2 壓入操作數(shù)棧
ALOAD 3
//str2追加一個數(shù)值1
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ICONST_1
INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder;
//基于toString 生成字符串
INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
ASTORE 53. final語義中的常量折疊
上文我們提到JIT會針對運行時常量進行常量折疊避免非必要的字符串運算，這是否意味著編碼時針對局部變量采用final修飾字符串就一定可以做到常量折疊呢？
來看看下面這個例子，我們通過final修飾兩個從靜態(tài)方法得出字符串的變量，然后進行拼接返回：
public static String function() {
final String str = getStr();
final String str2 = getStr();
return str + str2;
}
public static String getStr() {
return "hello";
}下面這段代碼就是function的字節(jié)碼，可以看到final語義在字節(jié)碼并沒有很實際的體現(xiàn)(和普通局部變量的JIT編譯后的代碼無異)，所有的字符串操作本質(zhì)上都是從靜態(tài)函數(shù)中獲取字符串然后通過StringBuilder完成拼接返回：
public static function()Ljava/lang/String;
//final String str = getStr();
L0
LINENUMBER 17 L0
INVOKESTATIC com/sharkchili/Main.getStr ()Ljava/lang/String;
ASTORE 0
// final String str2 = getStr();
L1
LINENUMBER 18 L1
INVOKESTATIC com/sharkchili/Main.getStr ()Ljava/lang/String;
ASTORE 1
//return str + str2;
L2
LINENUMBER 19 L2
NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder.<init> ()V
ALOAD 0
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 1
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
ARETURN對此我們不將代碼改一下，所有final語義的字符串直接顯示賦值字面量字符串：
public static String function() {
final String str = "hello";
final String str2 = "hello";
return str + str2;
}此時查看JIT編譯后的字節(jié)碼即可看到因為字符串return str + str2;分配的字符串直接就是上述兩個變量的拼接結(jié)果，由此可知，JIT對于final變量的優(yōu)化更多是針對編譯時常量即final修飾的字面量才能進行一定的優(yōu)化：
public static function()Ljava/lang/String;
//final String str = "hello";
L0
LINENUMBER 17 L0
LDC "hello"
ASTORE 0
// final String str2 = "hello";
L1
LINENUMBER 18 L1
LDC "hello"
ASTORE 1
//return str + str2;
L2
LINENUMBER 19 L2
LDC "hellohello"
ARETURN
L3
LOCALVARIABLE str Ljava/lang/String; L1 L3 0
LOCALVARIABLE str2 Ljava/lang/String; L2 L3 1
MAXSTACK = 1
MAXLOCALS = 2二、詳解final關(guān)鍵字在內(nèi)存模型中的語義
1. final域關(guān)于寫的重排序規(guī)則
實際上final關(guān)鍵字也能針對一些特殊場景插入內(nèi)存屏障從而避免一些指令重排序，它要求編譯器和處理器遵守下面這條規(guī)則：
對于一個構(gòu)造函數(shù)的初始化，涉及的final域的寫，與隨后把這個構(gòu)造對象引用到外部引用，這兩個操作之間不能重排序。
例如，我們用final修飾User類的成員變量name，執(zhí)行new操作時，按照final的語義它會在name初始化后面插入一個storestore屏障，保證name初始化完成之后，user對象才能發(fā)布：
對應(yīng)的我們也給出User類的定義：
public class User {
private final String name;
public User() {
name = "sharkchili";
//隱含的storestore內(nèi)存屏障
//隱式的 sharedRef = new User()和 return
}
}那么如果final關(guān)鍵字修飾會怎樣呢？我們都知道CPU為了提升指令執(zhí)行效率是允許前后沒有依賴的指令亂序執(zhí)行的，所以我們不妨帶入下面這段代碼說明一下，首先我們先介紹一下這段代碼的含義：
- 線程0先執(zhí)行init，執(zhí)行new User并將引用賦值給obj
- 線程1后執(zhí)行，基于obj獲取name字段值
//線程0執(zhí)行初始化
public static void init(){
obj=new User();
}
public static String getName(){
//線程1的引用接住obj中的user
Object o=obj;
//返回user的名稱
return ((User)o).name;
}試想這樣一個場景，并發(fā)場景下線程0初始化user，在此期間如果線程1訪問user的name字段，如果沒有內(nèi)存屏障，很可能出現(xiàn)：
- return和name = "sharkchili";的指令重排序，未完全體的user提前發(fā)布
- 線程1訪問到的name的null值，導(dǎo)致一致性問題
而通過final修飾name之后，對應(yīng)的final成員變量初始化位置就會插入內(nèi)存屏障，從而保證線程1訪問到的name是user對象完成初始化后的值：
2. final域關(guān)于讀的重排序規(guī)則
對于final域的讀，JMM內(nèi)存模型規(guī)定了編譯器(注意只有編譯器)遵守下面這條規(guī)則：
對于包含final域的對象讀以及對應(yīng)的final域字段的讀，兩者不能發(fā)生重排序。
舉個例子，假設(shè)我們的線程0還是執(zhí)行user的初始化，將創(chuàng)建的user賦值給obj靜態(tài)引用:
private static final Object obj;
public static void init(){
obj=new User();
}線程2并發(fā)讀取obj和obj對應(yīng)的name的值：
public static void getName() {
//線程2的引用接住obj中的user
User user = obj;
//獲取user的name
String userName = user.name;
}我們試想一下下面這個雙線程并發(fā)讀user的場景，線程0執(zhí)行user創(chuàng)建，針對線程1的并發(fā)讀，我們不妨帶入obj有final修飾和沒有final修飾的場景：
- 假設(shè)user對象完成初始化過程中，因為obj和name都有final修飾，獲取obj和name操作沒有發(fā)生重排序，當(dāng)線程1讀取到一個非空的user，就一定能夠得到一個非空的name。
- 假設(shè)user對象完成初始化過程中，沒有final修飾，獲取obj和name操作發(fā)生重排序，極端情況就可能得到一個空的name和非空的user
所以，這才有了final語義中對于讀操作的重排序規(guī)則，在對象讀和對象final域讀這兩個先后順序之間，編譯器會插入一個loadload內(nèi)存屏障避免兩者重排序，從而保證user非空的情況下一定能夠讀到final域中的name。
3. final關(guān)鍵字中需要注意的逸出問題
final關(guān)鍵字通過內(nèi)存屏障避免指令重排序保證變量讀寫的正確性，但我還是需要在使用上明確避免對象的逸出，例如下面這初始化user并賦值給obj靜態(tài)引用的代碼：
@Data
public class User {
private final String name;
public static Object obj;
public User() {
name = "sharkchili";
obj = this;
}
}試想一下，在處理器進行構(gòu)造函數(shù)初始化時其內(nèi)部操作就可能非順序?qū)⒅噶罱挥刹煌碾娐穯卧獔?zhí)行，即：
- 先執(zhí)行obj = this;。
- 再對name進行字符串分配。
面對上述的指令重排序，線程1執(zhí)行如下代碼，判斷obj非空后獲取obj指向的user和name值：
public static void getName() {
if (obj!=null){
//線程2的引用接住obj中的user
User user = obj;
//獲取user的name
String userName = user.name;
}
}按照上述邏輯，即使構(gòu)造函數(shù)發(fā)生重排序(即obj=this提前)，它依然會得到一個非空的obj，步入邏輯，就可能因為指令重排序提前拿到obj進而獲取到一個空name值，所以盡管final語義帶有指令重排序的語義，我們在使用時也需要明確去避免對象的逸出：
三、詳解可見性下的哲學(xué)
1. 發(fā)布與逸出的把控
發(fā)布(publish)的定義即將內(nèi)部一些對象對外發(fā)布使得外部代碼可操作，使得發(fā)布可以操作或者修改這個變量，例如下面這段代碼，這就是最簡單的發(fā)布模式，它將set采用public修飾使其對外部類和線程都可見：
/**
* public修飾使外部代碼可見
*/
public static Set<String> set;
public void init() {
set = new HashSet<String>();
}在并發(fā)編程中我們務(wù)必要把控要發(fā)布的粒度，例如下面這段，我們僅僅是要求map保管我們的元素，但是getMap方法卻將私有變量map發(fā)布，這種通過公有方法返回或者非私有字段引用私有變量的做法我們統(tǒng)稱為不安全的發(fā)布，存在各種并發(fā)操作的風(fēng)險：
private ConcurrentHashMap<String, Object> map = new ConcurrentHashMap<>();
public void put(String key, Object obj) {
map.put(key, obj);
}
/**
* 通過方法將私有域?qū)ο蟀l(fā)布
* @return
*/
public ConcurrentHashMap<String, Object> getMap() {
return map;
}另一個典型例子就是下面這段代碼，我們僅僅需要通過構(gòu)造方法對外發(fā)布User實例，卻因為構(gòu)造方法的public修飾符使得this被隱式發(fā)布導(dǎo)致逸出，這也是一種典型的錯誤：
public class ThisEscape {
private String name="thisEscape";
/**
* 將內(nèi)部類存入list時，將this實例發(fā)布
* @param list
* @param name
*/
public ThisEscape(List<Object> list, String name) {
list.add(new ThisEscape.User(name));
}
class User {
private String name;
public User(String name) {
this.name = name;
}
}
}只有完全返回的的構(gòu)造才處于可預(yù)測和一致的狀態(tài)，這種做法及時構(gòu)造函數(shù)運行到代碼的最后一行，本質(zhì)上構(gòu)造的對象都不是完整且不爭取的被發(fā)布了：
而正確的做法是采用構(gòu)造私有，通過對外暴露一個初始化工廠發(fā)布內(nèi)部類：
/**
* 將構(gòu)造函數(shù)私有
*/
private ThisEscape() {
}
/**
* 對外暴露一個創(chuàng)建工廠方法安全構(gòu)造并添加user
* @param list
* @param name
*/
public static void addNewUser(List<Object> list, String name) {
list.add(new ThisEscape.User(name));
}最終調(diào)測結(jié)果如下，可以看到外部類的this實例構(gòu)造不再逸出：
2. 不安全的發(fā)布
下面這段代碼就是典型的就存在構(gòu)造發(fā)布不可見的情況，因為構(gòu)造函數(shù)初始化存在指令重排序，實際上下面這個構(gòu)造初始化可能存在：
- 初始化holder
- 發(fā)布holder
- 完成n的賦值
public class Holder {
private int n;
public Holder(int n) {
this.n = n;
}
public void assertSanity() {
if (n != n) {
throw new RuntimeException("Sanity check failed");
}
}
}所以如果線程并發(fā)初始化時，可能看到一個尚未初始化好的Holder ，使得其他并發(fā)線程通過assertSanity訪問這個變量就既有可能存在不一致而報錯的情況，所以必要時我們建議需要保證并發(fā)安全性的成員字段需要在構(gòu)造函數(shù)內(nèi)部采用final關(guān)鍵字修飾：
引發(fā)異常的場景如下所示，因為構(gòu)造函數(shù)的指令重排序等原因，顯示的訪問就可能存在線程2讀取不一致的情況。
這里也需要補充說明一下，這份代碼示例不知道是因為現(xiàn)代計算機性能優(yōu)勢還是JIT某種機制的優(yōu)化，即使筆者關(guān)閉了JIT優(yōu)化也未能復(fù)現(xiàn)這個錯誤，也希望有讀者如果復(fù)現(xiàn)，務(wù)必指導(dǎo)一下筆者不對的地方：
// 線程1：初始化Holder
new Thread(() -> {
holder = new Holder(RandomUtil.randomInt()); // 不安全發(fā)布
}).start();
new Thread(() -> {
while (holder == null) {
// 等待holder被初始化
}
holder.assertSanity(); // 可能拋出異常
}).start();3. 利用final域下不可變性的安全訪問
利用final不可變語義，在構(gòu)造時初始化需要被外部線程訪問的變量，在訪問時通過拷貝的方式安全發(fā)布對象到外部，保證所有線程對于共享變量的訪問是一致的。
就例如下面這段代碼，筆者在構(gòu)造函數(shù)上顯示完成數(shù)組arr初始化，后續(xù)線程對于該內(nèi)部變量的訪問一律以getArrayList為入口，其內(nèi)部邏輯采用拷貝的方式將變量發(fā)布讓其進行自由操作，而原有對象內(nèi)部元素對所有線程仍舊保持一致：
public class SafeAccessArr {
/**
* 使用final修飾在構(gòu)造函數(shù)初始化保證可見性和一致性
*/
private final int[] arr;
private final int len;
public SafeAccessArr(int[] arr) {
this.arr = arr;
this.len = arr.length;
}
//訪問時通過拷貝的方式安全發(fā)布
public int[] getArrayList(int len) {
if (this.len == len) {
return Arrays.copyOf(arr, len);
}
return null;
}
}對此，我們也給出安全發(fā)布的幾個要點：
- 使用final保證不可變
- 使用synchronized保證訪問的互斥
- 使用volatile修飾保證可見性
- 在靜態(tài)初始化函數(shù)中初始化一個對象引用(保證可見、一致、安全訪問)
4. 棧封閉技術(shù)在并發(fā)編程中的使用
實際上保證不可變性的手段還有一種名為棧封閉的技術(shù)，該技術(shù)利用線程棧私有的特性，將外部引用參數(shù)拷貝到內(nèi)部進行邏輯計算，然后利用Java語言的語義天生保證了基本類型的引用無法獲得即基本類型的不可變性，將計算結(jié)果直接返回交由外部使用。由此保證操作變量只有一個線程的局部引用操作，保證了線程安全和不可變性：
就像下面這段代碼，可以看到筆者針對容器計數(shù)的功能進行如下處理：
- 將外部全局操作的并發(fā)容器鍵值對拷貝的線程內(nèi)部的map中
- 進行需要的非空過濾計數(shù)，同時筆者使用的計數(shù)器是采用基本類型的int而非包裝類，保證引用只有局部線程持有，且返回結(jié)果也是基本類型保證不可變性
public int getValidCount(ConcurrentHashMap<String, Object> params) {
int count = 0;
//將外部參數(shù)拷貝到線程局部變量中
Map<String, Object> map = new HashMap<>();
map.putAll(params);
//進行有效計數(shù)
for (String key : map.keySet()) {
if (map.get(key) != null) {
count++;
}
}
return count;
}當(dāng)然維持對象引用的棧封閉時，程序員還是需要額外注意一下引用對象的逸出問題，例如上文示例中map 引用就局限在當(dāng)前線程棧內(nèi)，利用線程棧私有的特性，即使map是非線程安全的對象，也可以利用棧的特性保證即時運算的準確性。
5. 事實不可變對象
最后一種，也算是并發(fā)哲學(xué)中大道至簡的方式，即事實不可變用筆者的話也就是業(yè)務(wù)不可變，例如下面這段代碼：
private ConcurrentHashMap<Integer, Date> map = new ConcurrentHashMap<>();事實上Date對象的操作是非線程安全的，但是我們業(yè)務(wù)上的場景它是只讀即不可變的，在協(xié)定的情況下這段代碼也變?yōu)槭聦嵅豢勺兊牟l(fā)安全。
