並發編程的藝術（9）：final的使用和原理

1 共享模型之不可變

1.1 日期轉換的問題

問題提出

下面的代碼在運行時，由於 SimpleDateFormat 不是線程安全的

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
for (int i = 0 ; i < 10 ; i++) {
    
    new Thread(() -> {
    
        try {
    
            log.debug("{}", sdf.parse("1951-04-21"));
        } catch (Exception e) {
    
            log.error("{}", e);
        }
    }).start();
}

有很大幾率出現 java.lang.NumberFormatException 或者出現不正確的日期解析結果，例如：

19:10:40.859 [Thread-2] c.TestDateParse - {
    }

java.lang.NumberFormatException: For input string: ""
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Long.parseLong(Long.java:601)
    at java.lang.Long.parseLong(Long.java:631)
    at java.text.DigitList.getLong(DigitList.java:195)
    at java.text.DecimalFormat.parse(DecimalFormat.java:2084)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2162)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
    at java.text.DateFormat.parse(DateFormat.java:364)
    at cn.itcast.n7.TestDateParse.lambda$test1$0(TestDateParse.java:18)
    at java.lang.Thread.run(Thread.java:748)
    
19:10:40.859 [Thread-1] c.TestDateParse - {
    }

java.lang.NumberFormatException: empty String
    at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1842)
    at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
    at java.lang.Double.parseDouble(Double.java:538)
    at java.text.DigitList.getDouble(DigitList.java:169)
    at java.text.DecimalFormat.parse(DecimalFormat.java:2089)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2162)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
    at java.text.DateFormat.parse(DateFormat.java:364)
    at cn.itcast.n7.TestDateParse.lambda$test1$0(TestDateParse.java:18)
    at java.lang.Thread.run(Thread.java:748)
    
19:10:40.857 [Thread-8] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951
19:10:40.857 [Thread-9] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951
19:10:40.857 [Thread-6] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951
19:10:40.857 [Thread-4] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951
19:10:40.857 [Thread-5] c.TestDateParse - Mon Apr 21 00:00:00 CST 178960645
19:10:40.857 [Thread-0] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951
19:10:40.857 [Thread-3] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951

思路 - 同步鎖

這樣雖能解决問題，但帶來的是性能上的損失，並不算很好：

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
for (int i = 0; i < 50; i++) {
    
    new Thread(() -> {
    
        synchronized (sdf) {
    
            try {
    
                log.debug("{}", sdf.parse("1951-04-21"));
            } catch (Exception e) {
    
                log.error("{}", e);
            }
        }
    }).start();
}

思路 - 不可變

如果一個對象在不能够修改其內部狀態（屬性），那麼它就是線程安全的，因為不存在並發修改。這樣的對象在Java 中有很多，例如在 Java 8 後，提供了一個新的日期格式化類：

DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd");
for (int i = 0; i < 10; i++) {
    
    new Thread(() -> {
    
        LocalDate date = dtf.parse("2018-10-01", LocalDate::from);
        log.debug("{}", date);
    }).start();
}

可以看 DateTimeFormatter 的文檔：

@implSpec
This class is immutable and thread-safe.

不可變對象，實際是另一種避免競爭的方式。

1.2 不可變設計

另一個大家更為熟悉的 String 類也是不可變的，以它為例，說明一下不可變設計的要素

public final class String
    implements java.io.Serializable, Comparable<String>, CharSequence {
    
    /** The value is used for character storage. */
    private final char value[];
    /** Cache the hash code for the string */
    private int hash; // Default to 0
    // ...
}

1.2.1final 的使用

String類中很多屬性都是 final 的，final的作用有：

• 屬性用 final 修飾保證了該屬性是只讀的，不能修改
• 類用 final 修飾保證了該類中的方法不能被覆蓋，防止子類無意間破壞不可變性

1.2.2保護性拷貝

使用字符串時，也有一些跟修改相關的方法啊，比如 substring 等，那麼下面就看一看這些方法是如何實現的，就以 substring 為例：

public String substring(int beginIndex) {
    
    if (beginIndex < 0) {
    
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    int subLen = value.length - beginIndex;
    if (subLen < 0) {
    
        throw new StringIndexOutOfBoundsException(subLen);
    }
    return (beginIndex == 0) ? this : new String(value, beginIndex, subLen);
}

發現其內部是調用 String 的構造方法創建了一個新字符串，再進入這個構造看看，是否對 final char[] value 做出了修改：

public String(char value[], int offset, int count) {
    
    if (offset < 0) {
    
        throw new StringIndexOutOfBoundsException(offset);
    }
    
    if (count <= 0) {
    
        if (count < 0) {
    
            throw new StringIndexOutOfBoundsException(count);
        }
        if (offset <= value.length) {
    //返回空字符串
            this.value = "".value;
            return;
        }
    }
    
    if (offset > value.length - count) {
    
        throw new StringIndexOutOfBoundsException(offset + count);
    }
    //拷貝數組
    this.value = Arrays.copyOfRange(value, offset, offset+count);
}

結果發現也沒有，構造新字符串對象時，會生成新的 char[] value，對內容進行複制 。這種通過創建副本對象來避免共享的手段稱之為【保護性拷貝（defensive copy）】

1.2.3模式之享元

1.2.3.1 簡介

保護性拷貝的缺點就是需要不停地創建新的對象，因此，提出了享元模式。

Flyweight pattern：當需要重用數量有限的同一類對象時使用

wikipedia： A flyweight is an object that minimizes memory usage by sharing as much data as
possible with other similar objects

出自 “Gang of Four” design patterns，歸類 Structual patterns

1.2.3.2應用案例

JDK中很多類都用到了享元模式，比較典型的有基本數據類型對應的包裝類。其中的Boolean，Byte，Short，Integer，Long，Character 等包裝類提供了 valueOf 方法，例如 Long 的valueOf 會緩存 -128~127 之間的 Long 對象，在這個範圍之間會重用對象，大於這個範圍，才會新建 Long 對象：

public static Long valueOf(long l) {
    
    final int offset = 128;
    if (l >= -128 && l <= 127) {
     // will cache
        return LongCache.cache[(int)l + offset];
    }
    return new Long(l);
}

• Byte, Short, Long 緩存的範圍都是 -128~127
• Character 緩存的範圍是 0~127
• Integer的默認範圍是 -128~127最小值不能變，
  但最大值可以通過調整虛擬機參數 -Djava.lang.Integer.IntegerCache.high 來改變
• Boolean 緩存了 TRUE 和 FALSE

此外，String類也通過字符串常量池也是一種享元模式的實現，還有諸如BigDecimal類等。

注意
盡管我們說BigDecimal等類是線程安全的，但前面的案例顯示在多線程下使用BigDecimal等類還是會有線程安全問題，這是因為針對這些類中單個方法，雖然它是線程安全的，但在使用的時候，我們經常是在一個方法中==使用了類中多個方法（獲取值方法、運算方法），這時整個方法就不是原子性的，也就有了線程安全問題。==

1.2.3.3 自定義實現連接池

例如：一個線上商城應用，QPS 達到數千，如果每次都重新創建和關閉數據庫連接，性能會受到極大影響。 這時預先創建好一批連接，放入連接池。一次請求到達後，從連接池獲取連接，使用完畢後再還回連接池，這樣既節約了連接的創建和關閉時間，也實現了連接的重用，不至於讓龐大的連接數壓垮數據庫。

class Pool {
    
    // 1. 連接池大小,初始化後不可更改，因此用final修飾即可
    private final int poolSize;
    // 2. 連接對象數組
    private Connection[] connections;
    // 3. 連接狀態數組 0 錶示空閑， 1 錶示繁忙，因為同時可能有多個線程在修改數組，因此用原子數組
    private AtomicIntegerArray states;
    // 4. 構造方法初始化
    public Pool(int poolSize) {
    
        this.poolSize = poolSize;
        this.connections = new Connection[poolSize];
        this.states = new AtomicIntegerArray(new int[poolSize]);
        for (int i = 0; i < poolSize; i++) {
    
            connections[i] = new MockConnection("連接" + (i+1));
        }
    }
    // 5. 借連接
    public Connection borrow() {
    
        while(true) {
    
            for (int i = 0; i < poolSize; i++) {
    
                // 獲取空閑連接
                if(states.get(i) == 0) {
    
                    if (states.compareAndSet(i, 0, 1)) {
    
                        log.debug("borrow {}", connections[i]);
                        return connections[i];
                    }
                }
            }
            // 如果沒有空閑連接，當前線程進入等待，防止一直空轉占用cpu,等有連接可用了，在喚醒
            synchronized (this) {
    
                try {
    
                    log.debug("wait...");
                    this.wait();
                } catch (InterruptedException e) {
    
                    e.printStackTrace();
                }
            }
        }
    }
    // 6. 歸還連接
    public void free(Connection conn) {
    
        for (int i = 0; i < poolSize; i++) {
    
            if (connections[i] == conn) {
    
                states.set(i, 0);
                synchronized (this) {
    
                    log.debug("free {}", conn);
                    this.notifyAll();
                }
                break;
            }
        }
    }
}
class MockConnection implements Connection {
    
    private String mockname;
    // 實現略
}

使用連接池

Pool pool = new Pool(2);
for (int i = 0; i < 5; i++) {
    
    new Thread(() -> {
    
        Connection conn = pool.borrow();
        try {
    
            Thread.sleep(new Random().nextInt(1000));
        } catch (InterruptedException e) {
    
            e.printStackTrace();
        }
        pool.free(conn);
    }).start();
}

以上實現沒有考慮：

• 連接的動態增長與收縮
• 連接保活（可用性檢測）
• 等待超時處理
• 分布式 hash

對於關系型數據庫，有比較成熟的連接池實現，例如c3p0, druid等 對於更通用的對象池，可以考慮使用apache commons pool，例如redis連接池可以參考jedis中關於連接池的實現。

1.2.4原理之 final

1.2.4.1設置 final 變量的原理

有如下代碼

public class TestFinal {
    
    final int a = 20;
}

對應字節碼

0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: bipush 20
7: putfield #2 // Field a:I
<-- 寫屏障
10: return

final 變量的賦值也會通過 putfield 指令來完成，同樣在這條指令之後也會==加入寫屏障==，保證在其它線程讀到
它的值時不會出現為 0 的情况。

1.2.4.2讀取 final 變量的原理

測試代碼

public class test {
    
    final static int A =20;
    final static int B=Short.MAX_VALUE+1;
    final int C =20;
    final int D=Short.MAX_VALUE+1;
    
    public static void main(String[] args) {
    

        System.out.println(test0522.A);
        System.out.println(test0522.B);
        System.out.println(new test0522().C);
        System.out.println(new test0522().D);

    }

對應字節碼

    L0
    LINENUMBER 19 L0
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    BIPUSH 20
    INVOKEVIRTUAL java/io/PrintStream.println (I)V
   L1
    LINENUMBER 20 L1
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    LDC 32768
    INVOKEVIRTUAL java/io/PrintStream.println (I)V
   L2
    LINENUMBER 21 L2
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    NEW com/example/demo/com/example/demo/test0522
    DUP
    INVOKESPECIAL com/example/demo/com/example/demo/test0522.<init> ()V
    GETFIELD com/example/demo/com/example/demo/test0522.C : I
    INVOKEVIRTUAL java/io/PrintStream.println (I)V
   L3
    LINENUMBER 22 L3
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    NEW com/example/demo/com/example/demo/test0522
    DUP
    INVOKESPECIAL com/example/demo/com/example/demo/test0522.<init> ()V
    GETFIELD com/example/demo/com/example/demo/test0522.D : I
    INVOKEVIRTUAL java/io/PrintStream.println (I)V

可以清楚的看到，被final修飾的變量在變量值較小的時候直接從棧內存中獲取（bitpush，範圍-128-127）,當變量超出這個範圍時，則從常量池中獲取（ldc或sipush等），而沒有被final修飾的變量則從堆內存中獲取（getfield），final等於做了一個在讀取上的優化。

補充：

final修飾的靜態字段（數據類型為基本類型或String）在編譯時會生成ConstantValue屬性，在類加載的准備階段利用ConstantValue屬性初始化賦值

而沒有被final修飾或者非基本類型和String類型的靜態變量，盡管也有ConstantValue屬性，也是在<clint>方法中初始化(類加載的初始化階段)。

對於成員變量則是在創建對象時才會分配內存，其中被final修飾的需要在構造函數結束前初始化。

1.3 無狀態

在 web 階段學習時，設計 Servlet 時為了保證其線程安全，都會有這樣的建議，不要為 Servlet 設置成員變量，這種沒有任何成員變量的類是線程安全的。

因為成員變量保存的數據也可以稱為狀態信息，因此沒有成員變量就稱之為【無狀態】。比如Spring中的service和dao層bean，只要沒有設置成員變量，盡管它是單例且存在並發訪問的情况，依然是線程安全的。