生产真实案例：震惊，几条SQL把服务器干崩了，事后还大言不惭！

“确实在公司跟着老大能学到很多知识啊，之前确实也不怎么了解线程安全问题和一些解决方案，现在了解了，也终于基于不可变类实现了一个简单的功能，明天找老大帮我看看“，小菜心里想着，脸上露出了满意的微笑。

一、情景再现

上回说到：小菜在自己实现分配的统计商品详情接口调用次数的功能时，没注意线程安全问题，导致统计出来的结果数据与实际结果偏差较大，通过老王的耐心讲解，知道了背后产生问题的根本原因，也学到了几种并发问题的解决方案。

下班后，小菜自己尝试基于不可变类实现一个简单的功能，但是。。。

二、事与愿违

第二天，小菜早早来到公司，昨天自己想基于不可变类实现一个简单的功能，经过自己不懈的努力，终于“完成”了自己想象的功能，心里也是比较高兴的。就等着老王来公司后，给老王看看自己实现的功能。

正想着，小菜听到了老王说话的声音，原来是老王跟几个同事一起到公司了。看着老王走到了自己的工位上，小菜拿着自己的电脑来到老王身边说：”老大，我昨天学了不少并发问题的解决方案，对不可变类这种方式很感兴趣，回去后自己基于这种方式实现了一个小功能，你帮我看看实现的对吗？“。

老王听后说：“我看看，你给我简单说下实现的功能是啥？”。

“咱们乘坐高铁，在进站时不是都要通过身份证检票吗，我就想通过不可变类模拟实现一个检票的功能，这个检票功能支持并发访问，也就是同时支持多个人拿着身份证通过检票。

在实现上，我想的比较简单，就是通过一个名字和身份证编号来定义一个不可变类，表示一个用户，由这个不可变类支持线程安全。再由一个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却是张三的身份证编号，用户数据发生了错乱的现象，出现了线程安全问题”。

“这么说能听明白吗？”，老王又问小菜。

“嗯，这次明白了”，小菜回复到。

“那我们继续讲讲怎么写不可变类的代码吧”，老王接着说。

“好的”。

正当老王准备讲如何写不可变类的代码时，此时听到一个熟悉的声音，“王工，有个新的需求要和技术这边一起讨论下可行性，你参与一下呀？”，老王抬头一看，原来是产品经理，边说边往这边走，于是回了句：“好的”。

老王转过有来对小菜说：“那我们今天就到这儿，你先结合今天分析的内容，思考下怎么写不可变的类，有时间咱们再接着聊，我去开会”。（老王真特么是个大好人）。

“好的”，小菜接着说。

于是，老王拿着电脑跟产品经理去开会了，小菜回到了自己的工位，开始了一天的工作。。。

五、本章总结

本章，以场景故事的形式描述了不可变类存在的线程安全问题，以及对不可变类存在的线程安全问题进行了分析。

最后，可以在评论区写下你学完本章节的收获，祝大家都能学有所成，我们一起搞定高并发设计模式。