“確實在公司跟著老大能學到很多知識啊，之前確實也不怎么了解線程安全問題和一些解決方案，現在了解了，也終于基于不可變類實現了一個簡單的功能，明天找老大幫我看看“，小菜心里想著，臉上露出了滿意的微笑。
一、情景再現
上回說到：小菜在自己實現分配的統計商品詳情接口調用次數的功能時，沒注意線程安全問題，導致統計出來的結果數據與實際結果偏差較大，通過老王的耐心講解，知道了背后產生問題的根本原因，也學到了幾種并發問題的解決方案。
下班后，小菜自己嘗試基于不可變類實現一個簡單的功能，但是。。。
二、事與愿違
第二天，小菜早早來到公司，昨天自己想基于不可變類實現一個簡單的功能，經過自己不懈的努力，終于“完成”了自己想象的功能，心里也是比較高興的。就等著老王來公司后，給老王看看自己實現的功能。
正想著，小菜聽到了老王說話的聲音，原來是老王跟幾個同事一起到公司了。看著老王走到了自己的工位上，小菜拿著自己的電腦來到老王身邊說：”老大，我昨天學了不少并發問題的解決方案，對不可變類這種方式很感興趣，回去后自己基于這種方式實現了一個小功能，你幫我看看實現的對嗎？“。
老王聽后說：“我看看，你給我簡單說下實現的功能是啥？”。
“咱們乘坐高鐵，在進站時不是都要通過身份證檢票嗎，我就想通過不可變類模擬實現一個檢票的功能，這個檢票功能支持并發訪問，也就是同時支持多個人拿著身份證通過檢票。
在實現上，我想的比較簡單，就是通過一個名字和身份證編號來定義一個不可變類，表示一個用戶，由這個不可變類支持線程安全。再由一個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卻是張三的身份證編號，用戶數據發生了錯亂的現象，出現了線程安全問題”。
“這么說能聽明白嗎？”，老王又問小菜。
“嗯，這次明白了”，小菜回復到。
“那我們繼續講講怎么寫不可變類的代碼吧”，老王接著說。
“好的”。
正當老王準備講如何寫不可變類的代碼時，此時聽到一個熟悉的聲音，“王工，有個新的需求要和技術這邊一起討論下可行性，你參與一下呀？”，老王抬頭一看，原來是產品經理，邊說邊往這邊走，于是回了句：“好的”。
老王轉過有來對小菜說：“那我們今天就到這兒，你先結合今天分析的內容，思考下怎么寫不可變的類，有時間咱們再接著聊，我去開會”。（老王真特么是個大好人）。
“好的”，小菜接著說。
于是，老王拿著電腦跟產品經理去開會了，小菜回到了自己的工位，開始了一天的工作。。。
五、本章總結
本章，以場景故事的形式描述了不可變類存在的線程安全問題，以及對不可變類存在的線程安全問題進行了分析。
最后，可以在評論區寫下你學完本章節的收獲，祝大家都能學有所成，我們一起搞定高并發設計模式。
