Java基础之如果保证线程安全,synchronized关键字, Lock锁, Threadlocal关键字

深碍√TFBOYSˉ_ 2023-06-23 08:57 42阅读 0赞

# 1. 什么是线程安全? #

*  一段代码所在的进程中**有多个线程在同一时间段内运行**，而这些线程**可能会同时运行这段代码**。每次运行结果和单线程运行的**结果是一样**的，而且其他的变量的值也和预期的是一样的，**就是线程安全的**。  
    或者说，一个类或者程序所提供的接口,对于线程来说是不可拆分的操作; 或者多个线程之间的切换不会导致该接口的执行结果存在差异, 这也是线程安全的。
 *  其实线程安全不是一个“非黑即白”单项选择题。按照“线程安全”的安全程度由强到弱来排序可分为5类：**不可变,绝对线程安全,相对线程安全,线程兼容和线程对立**.  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]

1.  不可变  
    java中**不可变的对象一定是线程安全的**,无论是对象的方法实现还是方法的调用者,都不需要再采取任何的线程安全保障措施.如**final关键字修饰的数据不可修改，可靠性最高**。
2.  绝对线程安全  
    绝对的线程安全,一个类要达到“**不管运行时环境如何，调用者都不需要任何额外的同步措施**”通常需要付出很大的代价。
3.  **相对线程安全**(这是我们要达到的目的, 相对安全即可)  
    相对线程安全就是我们通常意义上所讲的一个类是“**线程安全**”的。  
    是指**线程单独运行是安全的, 但是涉及多个线程交互就不安全了.**  
    Java中大部分的线程安全类都属于相对线程安全的，如Vector、HashTable、CouncurrentHashMap, Collections的synchronizedCollection()方法保证的集合。
4.  线程兼容(也常见这种情况)  
    线程兼容就是我们通常意义上所讲的一个类**不是线程安全**的。  
    线程兼容是指**线程单独运行不安全, 涉及线程交互也不安全**。  
    Java中大部分的类都是属于线程兼容的, 如ArrayList和HashMap等。
5.  线程对立  
    线程对立是**指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码**。由于java语言天生就具有多线程特性，线程对立这种排斥多线程的代码是很少出现的。

# 2. 线程安全问题产生的原因是什么? #

我们使用java多线程的时候，最让我们头疼的莫过于多线程引起的线程安全问题，那么线程安全问题到底是如何产生的呢？  
**究其本质, 是因为多条线程操作同一数据的过程中，破坏了数据的原子性. 所谓原子性，就是不可再分性**. 换句话说就是当前线程在操作这一数据的过程中, 被其他线程打断或者抢占了数据, 这就是破坏了数据的原子性.

*  线程安全问题都是由**全局变量及静态变量**引起的, 也就是所谓的**公共变量.**
 *  若每个线程中对全局变量、静态变量只有**读操作**，而无写操作，一般来说，这个全局变量是线程安全的.
 *  若有多个线程同时执行**写操作**，一般都需要考虑线程同步，否则的话就可能影响线程安全.

# 3. 如何保证线程安全 #

*  线程的安全性问题体现

1.  原子性：一个或者多个操作在 CPU 执行的过程中不被中断的特性, 线程切换会破坏原子性.
2.  可见性：一个线程对共享变量的修改，另外一个线程能够立刻看到.
3.  顺序性:

*  解决方案  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]

## 3.1 synchronized关键字 ##

### 3.1.1 synchronized的理解 ###

`synchronized` 关键字解决的是多个线程之间访问资源的同步性，`synchronized`关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。  
另外，在 Java 早期版本中，synchronized 属于 `重量级锁`，效率低下.

在 Java 6 之后 Java 官方对从 JVM 层面对 `synchronized` 较大优化，所以现在的 `synchronized` 锁效率也优化得很不错了. JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销.  
详见博主下篇文章, java中的各种锁[java中的各种锁][java]

### 3.1.2 synchronized的使用 ###

##### 1. synchronized修饰实例方法 #####

修饰实例方法: 作用于当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁

synchronized void method() { 
      //业务代码
    }

##### 2. synchronized修饰静态方法 #####

synchronized修饰静态方法, 锁对象是当前类的class对象.

synchronized void staic method() { 
      //业务代码
    }

##### 3. synchronized修饰代码块 #####

synchronized修饰代码块, 锁对象就是小括号内的对象, 其实也是当前的类的class对象.

synchronized(this) { 
      //业务代码
    }

## 3.2 java.util.concurrent.locks下的锁 ##

### 3.2.1 什么是lock锁 ###

在java.util.concurrent.locks 包下, 提供了Lock和ReadWritelLock两个接口  
Lock和ReadWriteLock是两大锁的根接口，Lock代表实现类是ReentrantLock（可重入锁），ReadWriteLock（读写锁）的代表实现类是ReentrantReadWriteLock。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 2]

*  Lock.RenntrantLock  
    其中 lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的，unLock()方法是用来释放锁的 。
 *  ReadWriteLock.ReentrantReadWriteLock  
    ReentrantLock是一种排他锁，同一时刻只允许一个线程访问，ReadWriteLock 接口的实现类 ReentrantReadWriteLock 读写锁提供了两个方法：readLock()和writeLock()用来获取读锁和写锁，也就是说将文件的读写操作分开，分成2个锁来分配给线程，从而使得多个线程可以同时进行读操作。

### 3.2.2 synchronized关键字和Lock锁区别 ###

*  首先synchronized是java内置关键字，在jvm层面Lock是个JUC（java.util.concurrent）的java类, ReentrantLock继承了Lock锁.  
    Lock锁会让JVM花较少的时间调度线程，性能更好，子类多扩展性好.  
    优先顺序 Lock锁 > synchronized (obj) \{…\} > synchronized func()
 *  synchronized无法判断是否获取锁的状态，Lock可以判断是否获取到锁；
 *  synchronized会自动释放锁(a 线程执行完同步代码会释放锁 ；b 线程执行过程中发生异常会释放锁). Lock需在finally中手工释放锁（unlock()方法释放锁），否则容易造成线程死锁；
 *  synchronized的锁是可重入锁、不可中断, 非公平锁. 而Lock锁可重入、可中断(两者皆可), 公平锁, 排他锁.
 *  Lock只有代码块锁，而 synchronized 有代码块锁和方法锁.
 *  Lock锁适合大量同步的代码的同步问题，synchronized锁适合代码少量的同步问题。

## 3.3 CAS算法 ##

CAS全称为Compare And Swap即比较并交换，其算法公式如下：CAS(V,E,N)  
CAS指令指令需要有3个操作数.

*  内存地址（在java中理解为变量的内存地址,用V表示）
 *  旧的预期值(用E表示)
 *  新值(用N表示).

CAS指令执行时,**当且仅当V处的值符合旧预期值E时, 处理器用N更新V处的值, 否则它就不执行更新**, 但是无论是否更新了V处的值, 都会返回V的旧值, 上述的处理过程是一个原子操作.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 3]  
JDK里面提供了很多Atomic类，AtomicInteger,AtomicLong,AtomicBoolean等等。它们是通过**CAS完成原子性**。

*  我们来看下**AtomicInteger的incrementAndGet()方法**  
    ![在这里插入图片描述][20191220120514785.png]
 *  再看getAndAddInt()方法：  
    ![在这里插入图片描述][20191220134731399.png]
 *  这里调用了**compareAndSwapInt()方法**, 所以这些Atomic类是线程安全的.

## 3.4 volatile关键字 ##

### 3.4.1 volatile关键字理解 ###

*  在多个线程读取共享变量时, 能保证每个线程读取到共享变量的最新值.
 *  代码在执行的过程中的先后顺序, Java 在编译器以及运行期间的优化, 代码的执行顺序未必就是编写代码时候的顺序. volatile 关键字可以禁止指令进行重排序优化, 保证代码按着编写的顺序执行. 最典型的应有就是**双重校验锁实现对象单例（线程安全）**

public class Singleton { 
        private volatile static Singleton uniqueInstance;
        private Singleton() { 
        }
        public static Singleton getUniqueInstance() { 
           //先判断对象是否已经实例过，没有实例化过才进入加锁代码
            if (uniqueInstance == null) { 
                //类对象加锁
                synchronized (Singleton.class) { 
                    if (uniqueInstance == null) { 
                        uniqueInstance = new Singleton();
                    }
                }
            }
            return uniqueInstance;
        }

1.  需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。
2.  uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：  
    为 uniqueInstance 分配内存空间  
    初始化 uniqueInstance  
    将 uniqueInstance 指向分配的内存地址
3.  但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。
4.  使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

### 3.4.2 synchronized和volatile的区别 ###

`synchronized` 关键字和 `volatile` 关键字是两个互补的存在，而不是对立的存在！

*  `volatile` 关键字是线程同步的轻量级实现，所以**volatile 性能肯定比synchronized关键字要好。但是volatile 关键字只能用于变量而 synchronized 关键字可以修饰方法以及代码块**。
 *  `volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。
 *  `volatile` 关键字主要用于解决变量在多个线程之间的**可见性**，而 `synchronized` 关键字解决的是多个线程之间访问资源的**同步性**。

## 3.5 ThreadLocal ##

### 3.5.1 ThreadLocal的理解 ###

*  ThreadLocal是每个线程内部的一个局部变量, 能够保证在读取公共变量时, 每个线程互不干扰, 达到了线程隔离的作用.
 *  每个Thread内部有一个ThreadLocalMap类型的成员变量threadLocals, ThreadLocalMap内部有个Entry\[\]数组，用于存放绑定的值。
 *  ThreadLocal本身并不存储值，它只是作为一个key来让线程从ThreadLocalMap中获取value。  
    我们可以简单的这样理解，ThreadLocal对象就好比是一个用于给Thread对象绑定值的工具类，当调用ThreadLocal对象的set（v）方法时，它会先获取当前线程对象thread，然后找到thread对象自己内部的ThreadLocalMap对象 map，然后把ThreadLocal对象作为key，v作为值存进map中，map中是用Entry。
 *  ThreadLocal的内存泄漏问题避免
    
     *  从源码中我们可以看到，ThreadLocal对象是被Thread\#ThreadLocalMap\#Entry对象以弱引用的方式引用的，也就是entry对象是个弱引用.
     *  那么当把ThreadLocal设置为null时，ThreadLocal对象的可见行就变成了弱可见，弱可见对象的特点是当GC发现时entry对象就会被回收.
     *  但是ThreadLocalMap生命周期和Thread是一样的，只要Thread还运行就不会被GC回收，这时候就会导致Thread\#ThreadLocalMap\#Entry这个对象继续存在, 但因为ThreadLocal对象为null了,也就是entry对象中的key为null, 也就是entry对象无法被使用了，这就是所谓的内存泄漏。
     *  简单说就是，如果把ThreadLocal对象设置为null了，但是通过其绑定的value还依然绑定在Thread中，但是却无法使用这个值，这就是所谓的内存泄漏。  
        解决办法：在设置ThreadLocal为null前，先执行ThreadLocal的remove操作，把值销毁，避免出现内存溢出情况。

### 3.5.2 ThreadLocal和volatile的区别 ###

*  `ThreadLocal`是线程的局部变量, 而`volatile`是关键字
 *  `ThreadLocal`能保证线程的可见性, 是保证多个线程能读取共享变量的初始值, 而且能保证线程隔离, 各个线程之间操作此共享变量互不影响.
 *  `volatile`也能保证线程的可见性, 但是它保证的是多个线程读取到共享变量的最新值.可以理解为和ThreadLocal是相反的.

# 4. 总结 #

综上所述,

*  synchronized/Lock锁/CAS算法能保证线程的原子性, 可见性, 顺序性.大量同步代码使用Lock锁, 少量同步代码使用synchronized关键字.
 *  ThreadLocal和volatile能够保证线程的可见性, volatile还能保证线程的顺序性.
 *  其实JUC(java.util.concurrent)java并发包下提供了挺多保证线程安全的工具, Lock锁就是JUC并发包下的接口, 还有Atomic原子类, volatile关键字, ConcurrentHashMap等.

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191218114926202.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210216112023540.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ==,size_16,color_FFFFFF,t_70
[java]: https://blog.csdn.net/weixin_42641909/article/details/106644887
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210114174820858.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210103172011999.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ==,size_16,color_FFFFFF,t_70
[20191220120514785.png]: https://img-blog.csdnimg.cn/20191220120514785.png
[20191220134731399.png]: https://img-blog.csdnimg.cn/20191220134731399.png