“确实在公司跟着老大能学到很多知识啊，之前确实也不怎么了解线程安全问题和一些解决方案，现在了解了，也终于基于不可变类实现了一个简单的功能，明天找老大帮我看看“，小菜心里想着，脸上露出了满意的微笑。
一、情景再现
上回说到：小菜在自己实现分配的统计商品详情接口调用次数的功能时，没注意线程安全问题，导致统计出来的结果数据与实际结果偏差较大，通过老王的耐心讲解，知道了背后产生问题的根本原因，也学到了几种并发问题的解决方案。
下班后，小菜自己尝试基于不可变类实现一个简单的功能，但是。。。
二、事与愿违
第二天，小菜早早来到公司，昨天自己想基于不可变类实现一个简单的功能，经过自己不懈的努力，终于“完成”了自己想象的功能，心里也是比较高兴的。就等着老王来公司后，给老王看看自己实现的功能。
正想着，小菜听到了老王说话的声音，原来是老王跟几个同事一起到公司了。看着老王走到了自己的工位上，小菜拿着自己的电脑来到老王身边说：”老大，我昨天学了不少并发问题的解决方案，对不可变类这种方式很感兴趣，回去后自己基于这种方式实现了一个小功能，你帮我看看实现的对吗？“。
老王听后说：“我看看，你给我简单说下实现的功能是啥？”。
“咱们乘坐高铁，在进站时不是都要通过身份证检票吗，我就想通过不可变类模拟实现一个检票的功能，这个检票功能支持并发访问，也就是同时支持多个人拿着身份证通过检票。
在实现上，我想的比较简单，就是通过一个名字和身份证编号来定义一个不可变类，表示一个用户，由这个不可变类支持线程安全。再由一个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却是张三的身份证编号，用户数据发生了错乱的现象，出现了线程安全问题”。
“这么说能听明白吗？”，老王又问小菜。
“嗯，这次明白了”，小菜回复到。
“那我们继续讲讲怎么写不可变类的代码吧”，老王接着说。
“好的”。
正当老王准备讲如何写不可变类的代码时，此时听到一个熟悉的声音，“王工，有个新的需求要和技术这边一起讨论下可行性，你参与一下呀？”，老王抬头一看，原来是产品经理，边说边往这边走，于是回了句：“好的”。
老王转过有来对小菜说：“那我们今天就到这儿，你先结合今天分析的内容，思考下怎么写不可变的类，有时间咱们再接着聊，我去开会”。（老王真特么是个大好人）。
“好的”，小菜接着说。
于是，老王拿着电脑跟产品经理去开会了，小菜回到了自己的工位，开始了一天的工作。。。
五、本章总结
本章，以场景故事的形式描述了不可变类存在的线程安全问题，以及对不可变类存在的线程安全问题进行了分析。
最后，可以在评论区写下你学完本章节的收获，祝大家都能学有所成，我们一起搞定高并发设计模式。
