博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
浅谈synchronized、Lock、ThreadLocal和semaphore
阅读量:5919 次
发布时间:2019-06-19

本文共 3942 字,大约阅读时间需要 13 分钟。

1. 背景

在进行多线程编程时,最让人头痛的无非是线程安全问题,对共享资源的访问控制,如果稍加不注意就可能导致莫名的错误,主要体现有:

  • 创建单例对象时,内存中可能存在多个实例。
  • 一个线程正在读取数据,由于另一个写线程的介入,可能导致读线程读取到的数据脏乱不堪。
  • 同一对象可能同时被多个线程使用,造成结果上面的偏差

2. synchronized 的介绍

为了防止多线程造成需要单例化的对象存在多实例问题,synchronized作为懒汉式模式创建实例的常使用的关键字,使用如下:

private SocketManager() {    }    private static SocketManager INSTANCE;    public static SocketManager getInstance() {        if (INSTANCE == null) {            synchronized (SocketManager.class) {                if (INSTANCE == null) {                    INSTANCE = new SocketManager();                }            }        }        return INSTANCE;    }复制代码

3. Lock的介绍

Lock是java中锁操作接口,比synchronized使用上面更为灵活。其主要实现类分为ReentrantLock (重入锁)和ReentrantReadWriteLock(读写锁)。其中ReentrantLock(重入锁)构造时,由于布尔参数不同又分为公平重入锁和非公平重入锁,其中非公平的重入锁处理效率比公平重入锁高,所以在创建时,一般使用ReentrantLock(false)。 另一个ReentrantReadWriteLock专门用于对读写操作的加锁(两个读线程不会冲突,两个写线程会冲突,一个读一个写线程会冲突,但是两个读线程不会冲突),如果ReentrantLock处理能力就不够,再这个情况下使用ReentrantLock。总之,一般情况下,ReentrantLock基本就能处理问题,在读写上就可以选择使用ReentrantLock处理。

private static ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock(true);    //HashMap 非线程安全    public static HashMap
pairs = new HashMap<>(); public static void setPair(int key, String value) { reentrantReadWriteLock.writeLock().lock(); pairs.put(key, value); reentrantReadWriteLock.writeLock().unlock(); } public static String getValue(int key) { reentrantReadWriteLock.readLock().lock(); String value = pairs.get(key); reentrantReadWriteLock.readLock().unlock(); return value; }复制代码
  • 以下case引用于:

Case 1 : 在使用synchronized关键字的情形下,假如占有锁的线程由于要等待IO或者其他原因(比如调用sleep方法)被阻塞了,但是又没有释放锁,那么其他线程就只能一直等待,别无他法。这会极大影响程序执行效率。因此,就需要有一种机制可以不让等待的线程一直无期限地等待下去(比如只等待一定的时间 (解决方案:tryLock(long time, TimeUnit unit)) 或者 能够响应中断 (解决方案:lockInterruptibly())),这种情况可以通过 Lock 解决。

Case 2 : 我们知道,当多个线程读写文件时,读操作和写操作会发生冲突现象,写操作和写操作也会发生冲突现象,但是读操作和读操作不会发生冲突现象。但是如果采用synchronized关键字实现同步的话,就会导致一个问题,即当多个线程都只是进行读操作时,也只有一个线程在可以进行读操作,其他线程只能等待锁的释放而无法进行读操作。因此,需要一种机制来使得当多个线程都只是进行读操作时,线程之间不会发生冲突。同样地,Lock也可以解决这种情况 (解决方案:ReentrantReadWriteLock) 。

Case 3 : 我们可以通过Lock得知线程有没有成功获取到锁 (解决方案:ReentrantLock) ,但这个是synchronized无法办到的。

4. ThreadLocal的介绍

前面讲的都是在多线程情况下,共享资源保持一致性,保证对象的唯一性。但是在某些情境中,同一对象需要在不同线程中相互独立,即每一个线程中都拥有该对象的一个副本。(PS: SimpleDateForma非线程安全)

// 测试代码public class Main {    public static void main(String... args) {        for (int i = 0; i < 5; i++) {            new Thread() {                @Override                public void run() {                    CountUtils.addCount();                }            }.start();        }    }}复制代码
// 没有使用ThreadLocal public class CountUtils {    private static int countNum = 0;    public static void addCount() {        synchronized (CountUtils.class) {            countNum++;            System.out.println(Thread.currentThread().getName() + ":" + countNum);        }    }}// 输出结果:Thread-1:1Thread-3:2Thread-2:3Thread-0:4Thread-4:5复制代码
  • 静态字段位于全局区,同时能够被多个线程修改。
public class CountUtils {    private static ThreadLocal
integerThreadLocal = new InheritableThreadLocal
() { @Override protected Integer initialValue() { return 0; } }; public static void addCount() { synchronized (CountUtils.class) { int countNum = integerThreadLocal.get(); countNum ++ ; System.out.println(Thread.currentThread().getName() + ":" + countNum); } }}// 输出结果:Thread-2:1Thread-1:1Thread-3:1Thread-0:1Thread-4:1复制代码
  • 总结: ThreadLocal采用Map<ThreadInfo,E>方式将线程操作的对象进行区分,不同的线程取值并非同一个。

5. semaphore的介绍

semaphore (信号量) 控制线程的出入问题,创建该对象时指明可用的资源数(synchronized可用资源数为1),当有资源空闲时,线程可进入,否则阻塞等待。项目中弹幕处理,维护弹幕池可用弹幕总数,当显示的弹幕已经达到弹幕总数,信号量为0,当某一弹幕移除屏幕,将弹幕控件放入弹幕控件池进行复用,并将信号量加1,定时器定时判断信号量,当信号量不为0时,从弹幕控制池取弹幕控件展示。

  • tryAcquire() : 仅在调用时此信号量存在一个可用许可,才从信号量获取许可。
  • acquire() : 从此信号量获取一个许可,在提供一个许可前一直将线程阻塞,否则线程被中断。
  • release() : 释放一个许可,将其返回给信号量。

转载于:https://juejin.im/post/5b8a2f1be51d453887105dc9

你可能感兴趣的文章