线程安全问题
主要是在多线程的环境下,不同线程同时读和写公共资源(临界资源)导致的数据异常问题。
保证线程安全的方法
无状态
我们都知道只有多个线程访问线程资源的时候,才会出现数据安全问题。
那么如果没有公共资源,就不存在线程安全问题了。
图中这个例子中NoStatusService没有定义公共资源。换句话说是无状态的,这种场景中,NoStatusService肯定是线程安全的。
不可变
如果多个线程访问的公共资源是不可变的,也不会出现数据的安全性问题。
图中DEFAULTNAME被定义成了static final的常量,在多线程环境中不会被修改。所以这种情况,也不会出现线程安全问题。
无修改权限
我们定义了公共资源,但是该资源只暴露了读取的权限,没有暴露修改的权限。这样也是线程安全的。
图中这个例子中没有对外暴露修改name字段的入口,所以不存在线程安全问题。
synchronized
使用JDK内部提供的同步机制,这也是使用比较多的手段,分为同步方法和同步代码块。
我们优先使用同步代码块。因为同步方法的粒度是整个方法。范围太大,相对来说,更消耗代码的性能。
其实,每个对象内部都有一把锁。只有抢到那把锁的线程才被允许进入对应的代码块执行相应的代码。当代码块执行完之后,JVM底层会自动释放那把锁。
lock
Lock除了使用synchronized关键字来实现同步功能之外,JDK还提供了Lock接口。
这种显示锁的方式,通常我们会使用Lock接口的实现类ReentrantLock。它包含了公平锁、非公平锁、可重入锁、读写锁等更多更强大的功能。
但如果使用ReentrantLock,它也带来了个小问题就是需要在finnally代码块中手动释放锁。
不过,在使用Lock显示锁的方式解决线程安全问题,给开发人员提供了更多的灵活性。
分布式锁
分布式锁如果是在单机的情况下,使用synchronized和Lock保证线程安全是没有问题的。
但如果在分布式的环境中,即某个应用如果部署了多个节点,每个节点可以使用synchronized和Lock保证线程安全。但不同的节点之间,没法保证线程安全。
这就需要使用分布式锁了。
分布式锁的分类
数据库分布式锁、zookeeper分布式锁、redis分布式锁等。
其中更加推荐使用redis分布式锁。其效率相对来说更高一些。
使用redis分布式锁的伪代码如图所示:
同样需要在finally代码块中释放锁。
volatile
有时候,我们有这样的需求,有任意一个线程,把某个开关的状态设置为false,则整个功能停止。
简单的需求分析之后发现,只要求多个线程间的可见性,不要求原子性。如果一个线程修改了状态。其他的所有线程都能获取到最新的状态值。
这样一分析就好办了。使用volatile就能快速满足需求。
ThreadLocal
除了上面几种解决思路之外,JDK还提供了另外一种用空间换时间的新思路。
当然ThreadLocal并不能完全取代锁,特别是在一些秒杀更新库存中,必须使用锁。
ThreadLocal的核心思想是共享变量在每个线程都有一个副本,每个线程操作的都是自己的副本,对另外的线程没有影响。
线程安全集合
有时候我们需要使用的公共资源放在某个集合当中,比如ArrayList、HashMap、HashSet等。
如果在多线程环境中,有线程往这些集合中写数据。另外的线程从集合中读数据,就可能会出现线程安全问题。
为了解决集合的线程安全问题,JDK专门给我们提供了能够保证线程安全的集合,比如CopyOnWriteArrayList、ConcurrentHashMap、CopyOnWriteArraySet、ArrayBlockingQueue等等。
在JDK底层或者Spring框架当中,使用ConcurrentHashMap保存加载配置参数的场景非常多。
比较出名的是spring的refresh方法中会读取配置文件,把配置放到很多的ConcurrentHashMap缓存起来。
CAS
JDK除了使用锁的机制解决多线程情况下数据安全问题之外,还提供了CAS机制。
这种机制是使用CPU中比较和交换指令的原子性。
JDK里面是通过Unsafe类实现的,CAS内部包含了四个值。旧数据、期望数据、新数据和地址,比价旧数据期望的数据,如果一样的话,就把旧数据改成新数据。如果不一样的话,当前线程不断自旋,一直到成功为止。
不过使用CAS保证线程安全,可能会出现ABA问题,需要使用AtomicStampedReference增加版本号来解决。
其实实际工作中很少直接使用Unsafe类的,一般用atomic包下面的类即可。
数据隔离
有时候,我们在操作集合数据时,可以通过数据隔离,来保证线程安全,使用线程池处理用户信息。
每个用户只被线程池中的一个线程处理。不存在多个线程同时处理一个用户的情况,所以这种人为的数据隔离机制也能保证线程安全。
数据隔离还有另外一个场景,kafka生产者把同一个订单的消息发送到同一个partion中,每个partion都部署一个消费者。在kafaka消费者中,使用单线程接收消息,并且做业务处理。这种场景下,从整体上看,不同的partion是用多线程处理数据的,但同一个partion则是用单线程处理的。
所以也能解决线程安全问题。
参考资料:Java中保证线程安全的11个小技巧