大家好，我是冰河~~

“確實在公司跟著老大能學到很多知識啊，之前確實也不怎么了解線程安全問題和一些解決方案，現在了解了，也終于基于不可變類實現了一個簡單的功能，明天找老大幫我看看“，小菜心里想著，臉上露出了滿意的微笑。

一、情景再現

上回說到：小菜在自己實現分配的統計商品詳情接口調用次數的功能時，沒注意線程安全問題，導致統計出來的結果數據與實際結果偏差較大，通過老王的耐心講解，知道了背后產生問題的根本原因，也學到了幾種并發問題的解決方案。

下班后，小菜自己嘗試基于不可變類實現一個簡單的功能，但是。。。

二、事與愿違

第二天，小菜早早來到公司，昨天自己想基于不可變類實現一個簡單的功能，經過自己不懈的努力，終于“完成”了自己想象的功能，心里也是比較高興的。就等著老王來公司后，給老王看看自己實現的功能。

正想著，小菜聽到了老王說話的聲音，原來是老王跟幾個同事一起到公司了。看著老王走到了自己的工位上，小菜拿著自己的電腦來到老王身邊說：”老大，我昨天學了不少并發問題的解決方案，對不可變類這種方式很感興趣，回去后自己基于這種方式實現了一個小功能，你幫我看看實現的對嗎？“。

老王聽后說：“我看看，你給我簡單說下實現的功能是啥？”。

“咱們乘坐高鐵，在進站時不是都要通過身份證檢票嗎，我就想通過不可變類模擬實現一個檢票的功能，這個檢票功能支持并發訪問，也就是同時支持多個人拿著身份證通過檢票。

在實現上，我想的比較簡單，就是通過一個名字和身份證編號來定義一個不可變類，表示一個用戶，由這個不可變類支持線程安全。再由一個Map來存儲這些用戶的信息，當用戶通過檢票時，更新下用戶的信息，最終打印出來。整個過程基于不可變類實現線程安全”。

“我還畫了一張圖”，說著小菜從電腦里打開了自己畫的場景需求圖，如圖4-1所示。

老王聽了后說：“嗯，我大概明白你的需求了，我看看代碼實現”。

于是小菜便把電腦給了老王，要不說老王是大牛呢？老王只是用他那凌厲的眼掃了一眼，便說道：“這代碼有問題”。

“啊”，小菜當時就有點懵，“這，我覺得沒問題呀”。。。

三、分析代碼

“那我們就結合代碼來分析下原因吧”，老王說著，便讓小菜看代碼。“首先是這個User用戶類”。

User類的源碼詳見：concurrent-design-patterns-immutable工程下的io.binghe.concurrent.design.demo.wrong.User。

public class User {

    private String name;
    private Long idCard;

    public void set(String name, Long idCard){
        this.name = name;
        this.idCard = idCard;
    }
    @Override
    public String toString() {
        return "User{" +
                "name='" + name + '\'' +
                ", idCard=" + idCard +
                '}';
    }
}

“這個User類就是有問題的，你知道什么是不可變類嗎？”，老王問小菜。

小菜說：“知道，就是一個類一經創建，就不會發生變化的類，就叫做不可變類”。

“對，概念記得倒是挺清楚的，但是這個User類不是一個不可變類呀，我們根據不可變類的定義分析下這個User類為什么不是一個不可變類”，老王巴拉巴拉的說了起來。總體上，老王針對User類為什么不是不可變類，總結了如下幾點：

• 用戶類沒有被final修飾，可以有其他類繼承User類，一旦有子類繼承，就可能改變User類的狀態。
• User類里的成員變量沒有被final修飾，可能會發生變化。
• User類中提供了修改成員變量的方法。成員變量可能發生變化。
• User類的set()方法也不是原子的，存在線程安全問題，多個線程同時訪問可能會存在并發問題。

“明白了嗎？”，老王問小菜。

“明白了”，小菜回答道，“其實我總覺得哪里有點怪，就是說不上來，我以為我寫的是對的”，小菜不好意思的笑了笑。

“那我們再來看看你寫的這個TicketCheck類”，老王繼續說道，說著打開了小菜寫的TicketCheck類的代碼片段。

TicketCheck類的源碼詳見：concurrent-design-patterns-immutable工程下的io.binghe.concurrent.design.demo.wrong.TicketCheck。

public class TicketCheck {

    private Map<String, User> userMap = new ConcurrentHashMap<>();

    public void updateUser(String userKey, String userName, Long idCard){
        User user = userMap.get(userKey);
        user.set(userName, idCard);
        System.out.println(Thread.currentThread().getName() + "--當前檢票的用戶是：" + user.toString());
        userMap.put(userKey, user);
    }

    public User getUser(String userKey){
        return userMap.get(userKey);
    }
}

“這個類也相對比較簡單”，老王繼續說道：“但是這類會改變User對象內部的狀態，User類本身就不是一個不可變類，加上TicketCheck類也確實通過用戶類的set()方法改變了用戶類的狀態，如果多個線程訪問了同一個userKey中的User對象，就可能會存在線程安全問題，所以整體不能基于不可變類保證線程安全”。

此時的小菜有點一臉懵逼，眉頭擰成了一個麻花。

老王看了一眼小菜，說到：“剛才我說的聽明白了嗎？”。

“有點聽不明白了”，我寫的TicketCheck類，其實并不是要修改User類，而是為User類設置userName和idCard屬性，實際并不會修改User類的信息，只是記錄檢票的用戶，并且打印用戶的信息，不太明白為啥不能基于不可變類保證線程安全“。

“這樣吧，我給你畫張圖分析一下”，老王說道。

于是，老王打開了電腦的畫圖工具。。。

四、畫圖分析

要不說老王這人就是牛，對其他同事也特別好呢，不一會，就畫出了一張分析圖，如圖4-2所示。

“我們就基于你寫的User類進行講解，看這張圖”，老王繼續說到，“假設現在user對象的name為張三，idCard為1001，線程1獲取到用戶信息時，此時的name為張三，idCard為1001，線程1調用user對象的set()方法來修改用戶的信息。我們來看user的set()方法”，老王又打開了User類的代碼，重點讓小菜看set()方法的代碼。

public void set(String name, Long idCard){
    this.name = name;
    this.idCard = idCard;
}

“在set()方法中，會分別修改user的name字段和idCard的值，這個過程并不是原子操作，線程1在執行set()方法時，在更新完name字段的值時，如果此時恰好發生了線程切換，線程2獲取用戶信息時，獲取到的用戶的name字段為張三，idCard字段為1001。這時，線程2獲取到的數據是錯亂的，線程2獲取到的用戶name字段為李四，idCard卻是張三的身份證編號，用戶數據發生了錯亂的現象，出現了線程安全問題”。

“這么說能聽明白嗎？”，老王又問小菜。

“嗯，這次明白了”，小菜回復到。

“那我們繼續講講怎么寫不可變類的代碼吧”，老王接著說。

“好的”。

正當老王準備講如何寫不可變類的代碼時，此時聽到一個熟悉的聲音，“王工，有個新的需求要和技術這邊一起討論下可行性，你參與一下呀？”，老王抬頭一看，原來是產品經理，邊說邊往這邊走，于是回了句：“好的”。

老王轉過有來對小菜說：“那我們今天就到這兒，你先結合今天分析的內容，思考下怎么寫不可變的類，有時間咱們再接著聊，我去開會”。（老王真特么是個大好人）。

“好的”，小菜接著說。

于是，老王拿著電腦跟產品經理去開會了，小菜回到了自己的工位，開始了一天的工作。。。

五、本章總結

本章，以場景故事的形式描述了不可變類存在的線程安全問題，以及對不可變類存在的線程安全問題進行了分析。