【Java系列】详解多线程（三）—— 线程安全（上篇）

逃离我推掉我的手 2024-04-27 07:09 84阅读 0赞

> 个人主页：[兜里有颗棉花糖][Link 1]  
> 欢迎 点赞? 收藏✨ 留言✉ 加关注?本文由 [兜里有颗棉花糖][Link 1] 原创  
> 收录于专栏【[Java系列专栏][Java]】【[JaveEE学习专栏][JaveEE]】  
> 本专栏旨在分享学习Java的一点学习心得，欢迎大家在评论区交流讨论?  
> ![在这里插入图片描述][494eb88c3281487e9915e824c8b9115b.png]

#### 目录 ####

*  一、Java线程的六种状态
 *  二、多线程带来的安全问题——线程安全（重点重点）
 *  三、线程不安全问题的原因
 *  四、解决线程不安全问题
 *   *  synchronized关键字
 *  五、总结

## 一、Java线程的六种状态 ##

**就绪状态和阻塞状态是线程的两种常见的状态，而Java中又对线程作了进一步的区分，即Java中总共有六种线程状态：**

*  **`新建状态（New）`：线程对象被创建后，但还没有调用start()方法启动线程时，线程处于新建状态。**

> **举个栗子：**  
> ![在这里插入图片描述][b3a85e8298d7466ca72af84beac8407a.png]  
> **运行结果如下：**  
> ![在这里插入图片描述][7df6a3fef07540d793125daa7c65acd8.png]

*  **`可运行状态（Runnable）`：就绪状态我们可以理解为两种情况，一种情况是线程正在CPU上运行，另外一种情况就是线程正在排队中，随时可以去CPU上运行。**

> **举个栗子：**  
> ![在这里插入图片描述][e7e32b207563409d98f47612af3b8c3a.png]  
> **上述代码属于可运行状态中的第二种情况，即线程正在CPU上运行。**  
> **代码运行结果如下：**  
> ![在这里插入图片描述][ae856baace4d4266895ced77af94fe1d.png]

*  **`阻塞状态（Blocked）`：因为锁的原因产生了阻塞。**
 *  **`等待状态（Waiting）`：因为调用wait方法产生了阻塞。**
 *  **`TIMED_WAITING`：因为调用sleep方法产生了阻塞。**

> **举例代码如下：**  
> ![在这里插入图片描述][fbbf542d84fe444cbd1984eadc392d4d.png]  
> **运行结果如下：**  
> ![在这里插入图片描述][97d1fcc0df2644b5b00e07ed7070d850.png]

*  **`守护状态（Terminated）`：线程已经执行结束了，但是该线程对应的Thread对象还在。**

> **举个栗子：**  
> ![在这里插入图片描述][882c58ab2f4d4118af0b1cbe0c528334.png]  
> **代码运行结果如下：**  
> ![在这里插入图片描述][4cda167aa3274b0fab84a3505c318568.png]

**注意，有的地方java线程分为了七种状态，即把可运行状态（runnable）拆分成了两种状态就绪状态（ready）和运行状态（running）。这个地方也是可以的。**

> **下图是线程状态转移图，请看：**  
> ![在这里插入图片描述][0f9466c7095f4875a4593d2f60b1f1df.png]

## 二、多线程带来的安全问题——线程安全（重点重点） ##

> **我们先来通过一段代码来进行线程安全问题的演示：**

class Counter {
        
        public int count = 0;
        public void increase() {
        
            count++;
        }
    }
    public class Demo12 {
        
        public static void main(String[] args) throws InterruptedException {
        
            Counter counter = new Counter();
            Thread t1 = new Thread(() ->{
        
                for(int i = 1;i <= 10000;i++) {
        
                    counter.count++;
                }
            });
            Thread t2 = new Thread(() ->{
        
                for(int i = 1;i <= 10000;i++) {
        
                    counter.count++;
                }
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println(counter.count);
        }
    }

**在上述代码运行之前我们先来复习以下之前的lambda表达式的变量捕获问题：线程t1和t2都引用了外部的Counter对象counter，并且在各自的run()方法中对count进行了自增操作。我们虽然对counter对象中的成员变量进行了修改，但是我们并没有修改counter对象本身。`注意线程t1和线程t2引用的是counter对象，而不是counter对象中的成员变量，所以这里依然可以触发变量捕获。`**

> **好了，现在回归正题，下面是上述代码的运行结果：**  
> ![在这里插入图片描述][11f66045b94046c8bba8b78aff578a46.png]  
> **好像结果并非我们所想的那样（两个线程针对同一个变量进行自增操作，结果应该是20000呀，但是…），那我们再运行一次试试呢，请看：**  
> ![在这里插入图片描述][d13f1f64a96a4abc9462608f4f241864.png]  
> **现在发现，运行结果发生了变化。我们称上述出现的问题为线程安全问题（多线程执行下产生的bug我们一般称之为线程安全问题；如果某段代码在单线程运行下没有问题，在多线程运行下依然没有问题，此时我们就可以称之为线程安全，反之如果出现问题我们就可以称之为线程不安全，正如上述代码而言就是线程不安全。）那现在我们如果让这两个线程单独执行的话，即先执行完线程t1，然后再执行完线程t2，线程就不会出现问题，如下：**  
> ![在这里插入图片描述][a90813b4a58b44b9b883bd53c041d269.png]

> **现在我们来分析一下上述代码中的线程安全问题：先来看`count++`操作，如果站在`CPU指令`的角度来说，`count++`操作是要分为三个步骤来进行执行的。第一步：把内存加载到CPU的寄存器中（load）；第二步：把寄存器中的数据进行+1；第三步：把寄存器中的数据写回到内存中（save）。**  
> **上述的count++操作的三个步骤如果是在两个线程或者多线程并发执行的情况下就有可能会出现问题。**  
> **虽然一个CPU核心上只有一个寄存器，但是我们可以视为两个线程或者多个线程各自可以有自己的一组寄存器，即这多个线程可以做到`分时复用`寄存器的（简单来说这一个寄存器这会可以给这个线程用，另一会可以给其它线程使用，以达到`分时复用`的效果）。**  
> ![在这里插入图片描述][a0711e16bf8d4def84831571be42a481.png]  
> 代码中的t1线程和t2线程的调度顺序是不确定的，当然两组指令操作的相对顺序也会存在差异，比如下图：  
> ![在这里插入图片描述][45c901546c174b88b18938975405427e.png]  
> ![在这里插入图片描述][eaf0ded160974b1b884805536a1a913b.png]  
> **当然情况有非常多种，就上述代码而言，由于线程t1和线程t2的调度顺序不同，两组指令的相对顺序存在非常多的差异，所以最终代码运行结果是不确定的。**  
> **我们就拿两次count自增操作为例，即一共六个指令操作，那么这六个指令在一定的执行顺序下就可能导致中间的运算结果被覆盖掉。`如下图就是一个典型的栗子：`**  
> ![在这里插入图片描述][4ba54a61ea7042bd8e53edf4bcd36f04.png]

> **综上，上述代码的count++执行的20000次自增操作，这两个线程执行count++的操作中有多少次是串行执行的，有多少次的执行结果是被覆盖掉的，我们是不确定的。`因为线程的调度执行是随机的，执行过程是抢占式的执行过程，从而导致这两个线程的指令执行顺序产生差异、变化，而这些差异变化就会导致每次程序运行的结果是不同的。当然也会导致线程安全问题。`**

## 三、线程不安全问题的原因 ##

*  **`根本原因`：多个线程的调度顺序是随机的，操作系统采用的是抢占式执行的策略来调度线程的。（我们以往只需要考略代码在一个固定的执行顺序下运行成功即可，但是我们现在要考虑的是代码需要在多线程中的所有执行顺序中都要正确执行代码才可以。）`那现在我们能不能想个办法让代码按照多线程的一定执行顺序下进行执行呢？很遗憾，现在我们还不能很好的解决这个问题。（当前主流的操作系统都是按照抢占式的执行顺序来执行的）`。**
 *  **`代码结构的原因`：多个线程同时修改同一个变量，此时容易发生线程安全问题。（`一个线程修改一个变量`、`多个线程读取同一个变量`，`多个线程修改多个变量`都是没有问题的）。**
 *  **进行的`修改`操作不是原子性的（比如上述代码中的count++操作就不是原子的，因为count++操作实质上是三条执行指令来完成的。），`反之我们如果我们的修改操作是原子性的，此时代码就不会产生线程安全问题`。另外关于原子的：一条java语句不一定是原子的，也不一定只是一条指令，比如count++就不是原子的、`=即直接赋值操作就是原子的`、`if=即先判断再赋值操也不是原子的`。**
 *  **内存可见性引起的线程安全问题。**
 *  **指令重排序引起的线程安全问题。**

## 四、解决线程不安全问题 ##

**关于如何解决线程不安全问题的话，最主要的一个切入点就是改变修改操作的非原子性，即将我们的修改操作改变成原子的。`我们可以通过加锁操作将一组操作给打包成一个操作，即打包成一个原子的操作。`**  
**注意：这里的给线程加锁的操作不同于数据库事务的原子操作：事务的原子操作依靠的主要是回滚；而这里的原子操作通过给线程加锁的操作将线程之间进行互斥，即这个线程在执行任务的时候，其它线程是无法执行任务的。`简单来说就是通过给线程加锁以实现在同一时刻的多个线程中，只有一个线程在执行任务`。**

> **如何给count++进行加锁操作呢？**  
> **Java中引入了关键字`synchronized`。**  
> 如下图：  
> ![在这里插入图片描述][8064e6182b4d4eb7bf9303362eb2a6d3.png]  
> 我们进入`increase方法`之后就会加锁（lock），出了increase方法之后就会解锁（unlock）。  
> ![在这里插入图片描述][9084a60f49d54670963d3ca7e3006f9c.png]

> **解释上图：当t1加锁之后，t2也尝试进行加锁，但是t2就会进入阻塞等待状态（这里t2的阻塞等待就是把t2的count++操作推迟到后面去执行，直到t1完成了count++操作之后，t2才能执行count++的操作），这个阻塞等待会一直持续到t1解锁之后（即t1解锁之后t2才能进加锁）；当t1解锁之后t2就会进行加锁操作。这里就相当于把指令的穿插式的执行变成了线程的串行执行。**  
> **上述代码t1的increase方法加减锁操作是要执行10000次的，t2的increase方法的加锁操作能够执行成功取决于t1执行到什么地方：如果t1执行到increase方法内部的话，此时t1的increase方法在占用锁，即t2的increase方法就必须要等待阻塞；直到t1的increase方法执行完释放锁时，t1的increase方法才能加锁成功（其实t1的increase方法占用锁的时间非常短，换言之t2的increase方法的阻塞等待时间非常短）（`注意t1线程和t2线程是同时执行的，并不存在说t1执行完才能执行t2线程`）。**  
> **此时我们来执行代码验证一下，请看：**  
> ![在这里插入图片描述][2e60a22a0ff24137b527e6c5b7c643a5.png]  
> 最终代码执行结果符合我们的预期。

> **好了，现在有个问题，上述代码我们通过加锁之后相当于一定程度上把并发执行变成了线程执行了，那多线程的意思又何在呢？又或者来说多线程还又存在的意义吗？**  
> **答案是多线程当然有存在的意义了：`我们虽然对increase方法进行了加锁操作，但是我们并没有对for循环进行加锁操作。for循环中的i变量是栈上的一个局部变量。而t1和t2两个线程是有两个独立的栈空间的，即两个for循环中的变量并不是同一个变量。既然这样的话，两个线程修改两个变量是不存在线程安全问题的。我们也不需要对i变量进行加锁操作。`**  
> **综上，上述代码的两个线程中，有一部分的代码是并发执行的，也有一部分代码是串行执行的，此时当然要比单纯的串行执行的效率高啦。**

### synchronized关键字 ###

> synchronized是java给我们提供的加锁的一种方式，synchronized是通过的搭配代码块的方式来进行加锁的（进入代码块就加锁，出来代码块（无论是正常出代码块，还是因为return退出，还是因为抛出异常而退出代码块**都能保证正常解锁**）就解锁）。  
> 补充一点：C++、python中的加锁方式是两个独立的方法。

**synchronized在进行加减锁操作的时候`是以对象为维度`进行展开的。**

> **使用synchronized的时候，其实是指定了某个具体的对象进行加锁。如下图：**  
> ![在这里插入图片描述][d9afa201305a4038b27e933659fb15e6.png]  
> **解释上述代码：当synchronized直接修饰方法的时候其实就相当于上图代码的针对this加锁（`直接修饰方法的写法其实就相当于上图代码的的简化写法`）`上面代码中的t1、t2线程就是针对同一个对象进行加锁的`。**  
> **如果两个线程针对同一个对象进行加锁的话就会存在锁竞争/锁冲突的问题（即一个线程加锁成功，另一个线程阻塞等待）。**  
> **如果两个线程针对不同的对象进行加锁的话此时就不会出现锁竞争，当然也就不会出现阻塞等待。但是此时两个线程按照也就不会按照串行执行的方式进行count++操作，此时就会存在线程安全问题。**

> **现在我们就两个线程针对不同的对象就行加锁（当然此时会出现线程安全问题）来进行举例：**  
> ![在这里插入图片描述][5f5a8ba5f98448de8ae98811dcb979b4.png]  
> **运行结果如下：**  
> ![在这里插入图片描述][a0be0a591935438b9afcf5083e126464.png]  
> **此时如果我们再次就两个线程对同一对象进行加锁（当然不会出现线程安全的问题，另外`针对的是哪个对象加锁并不是很重要，重要的是两个或者多个线程是不是针对同一个对象进行加锁`）的举例：**  
> ![在这里插入图片描述][c04f2996c193413fb5bdb8af3ce3ab75.png]  
> **运行结果如下：**  
> ![在这里插入图片描述][c2449c4f4b6a47d0a3538ca24a1090cc.png]

## 五、总结 ##

*  **`如果两个线程针对的是同一个对象进行加锁的话，此时就会产生阻塞等待，不会出现线程安全的问题。所以，必须多个线程对同一个对象加锁此时才有意义。`**
 *  **如果两个线程针对的是不同的对象进行加锁的话，此时也就不会出现阻塞等待，会出现线程安全的问题。**
 *  **如果两个线程中，一个线程加锁了而另一个线程没有加锁，此时依然会出现线程安全的问题（单方面加锁相当于没有加锁）。**

**好了，本文到这里就结束了，希望友友们可以支持一下一键三连哈。嗯，就到这里吧，再见啦！！！**  
![在这里插入图片描述][274f6664e780413aa44960d3d7a6a451.png]

[Link 1]: https://xiaofeizhu.blog.csdn.net/
[Java]: https://blog.csdn.net/m0_74352571/category_12520599.html
[JaveEE]: https://blog.csdn.net/m0_74352571/category_12524555.html?spm=1001.2014.3001.5482
[494eb88c3281487e9915e824c8b9115b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d81e6476103f461891647f8e981783fe.png
[b3a85e8298d7466ca72af84beac8407a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/4f47563c630c4cbc9a859be731582fe2.png
[7df6a3fef07540d793125daa7c65acd8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/9510814da8c14dd29943ace996a66aa3.png
[e7e32b207563409d98f47612af3b8c3a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d9e1c7d966ce410e8687a2513b168702.png
[ae856baace4d4266895ced77af94fe1d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/7de067cf277a4b198791d7cb8a201027.png
[fbbf542d84fe444cbd1984eadc392d4d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/9b98487b73634677898de5cdd17d354e.png
[97d1fcc0df2644b5b00e07ed7070d850.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/6df0f3857bca4b72849a1d82687ad411.png
[882c58ab2f4d4118af0b1cbe0c528334.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/a38e02fc22924c1c80af230ecea7fcb7.png
[4cda167aa3274b0fab84a3505c318568.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/b5994eb70b2d4f47b89bf34b7e116228.png
[0f9466c7095f4875a4593d2f60b1f1df.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/dc1a92f1c00448c18f48053a0910cbda.png
[11f66045b94046c8bba8b78aff578a46.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/c63784f334204c4cbff8589f17749e28.png
[d13f1f64a96a4abc9462608f4f241864.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/307dc4a6cfe448eab7fb1ee75259941e.png
[a90813b4a58b44b9b883bd53c041d269.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d825803d9d3c4f99905d3219fbc857f6.png
[a0711e16bf8d4def84831571be42a481.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/e84cf942e34c42a0b8e77fc715a7fc64.png
[45c901546c174b88b18938975405427e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/b84b3b18fd27466bbe0d62dc095d21ec.png
[eaf0ded160974b1b884805536a1a913b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/abdce5b670df4b5697825a2017305d74.png
[4ba54a61ea7042bd8e53edf4bcd36f04.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/2c70b92bf6694b5ebbb9739bf7ebac30.png
[8064e6182b4d4eb7bf9303362eb2a6d3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d4d05496c3b34aba9055efa67c9a7071.png
[9084a60f49d54670963d3ca7e3006f9c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/8298cb93ecec49f1b7464318e7202155.png
[2e60a22a0ff24137b527e6c5b7c643a5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/846804031c2d439b866354b40d8c32f4.png
[d9afa201305a4038b27e933659fb15e6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/0e6a7a9506ea4912b151e9c7a71c460a.png
[5f5a8ba5f98448de8ae98811dcb979b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/9aa0120871bc421faf08e569ca648609.png
[a0be0a591935438b9afcf5083e126464.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/513673e331944e88b08fa4f8cda91612.png
[c04f2996c193413fb5bdb8af3ce3ab75.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/1df3e93671724c968cce87b0583bea65.png
[c2449c4f4b6a47d0a3538ca24a1090cc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/67b7e4b4965443ba93b56713a8de415d.png
[274f6664e780413aa44960d3d7a6a451.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/6162eb978a0841af81452145f2ea21a4.png