JavaEE-多线程初阶(3)

目录

1.线程的状态

1.1 NEW、RUNNABLE、TERMINATED

1.2 TIMED_WAITING

1.3 WAITING

1.4 BLOCKED

2.多线程带来的风险-线程安全（重点）

2.1 观察线程不安全的现象

2.2 分析产生该现象的原因

2.3 产生线程安全问题的原因

2.3.1 抢占式执行（根本）

2.3.2 多个线程同时修改同一个变量

2.3.3 修改操作，不是原子的

2.3.4 内容可见性问题

2.3.5 指令从排序

2.4 如何解决线程安全问题

2.4.1 抢占式执行

2.4.2 多个线程同时修改同一个变量

2.4.3 修改操作，不是原子的

解决方案

加锁：synchronized

synchronized的变种写法

1.线程的状态

线程的所有状态如下：

• NEW: 安排了⼯作, 还未开始⾏动

• RUNNABLE: 可⼯作的. ⼜可以分成正在⼯作中和即将开始⼯作.

• BLOCKED: 这⼏个都表⽰排队等着其他事情

• WAITING: 这⼏个都表⽰排队等着其他事情

• TIMED_WAITING: 这⼏个都表⽰排队等着其他事情

• TERMINATED: ⼯作完成了.

1.1 NEW、RUNNABLE、TERMINATED

对于这三个状态的解释：

NEW：new了Thread对象，还没start

RUNNABLE ：就绪状态，可以分成以下两种情况（正在工作或者即将开始工作）：

（1）线程正在cpu上执行

（2）线程随时可以去cpu上执行

TERMINATED：内核中的线程已经结束了，但是Thread对象还在

    public static void main(String[] args) throws InterruptedException {
        Thread t1=new Thread(()->{
            System.out.println("线程t1开始执行...");
            try {
                Thread.sleep(1);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            System.out.println("t1线程结束...");
        });
        System.out.println(t1.getState());
        t1.start();
        Thread.sleep(0,500);
        System.out.println(t1.getState());
        t1.join();
        System.out.println(t1.getState());
    }

执行结果：

1.2 TIMED_WAITING

• 指定时间的阻塞

• 线程阻塞（不参与 cpu 调度，不继续执行了）

• 阻塞的时间是有上限的

Thread.sleep(时间);会进入到TIMED_WAITING状态

另外，join(时间)也会进入到TIMED_WAITING状态：

1.3 WAITING

死等，没有超时时间的阻塞等待

1.4 BLOCKED

也是一种阻塞，比较特殊，是由于锁导致的阻塞。

2.多线程带来的风险-线程安全（重点）

2.1 观察线程不安全的现象

案例：

创建一个静态变量count=0;

在main方法里创建两个线程t1和t2

两个线程内分别循环五万次count++操作

最后打印出count的值：

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

按照道理来说，count进行了总共十万次count++操作，打印出来的值应该是十万，实际上却并非如此，执行代码：

这样的代码很明显是有bug的，实际执行效果与预期效果不符合就叫做bug。

这样的问题，是多线程并发执行引发的问题。

如果调换代码的执行程序，把t1线程和t2线程的并行改成串行（一个执行完了再执行另一个）

结果又变成正确的了：

执行结果：

很明显，当前的bug是由于多线程的并发执行代码引起的bug

这样的bug，就称为“线程安全问题”，或者叫做“线程不安全”

反之，如果一个代码在多线程并发执行的环境下也不会出现类似上述的bug

这样的代码就称为“线程安全”

2.2 分析产生该现象的原因

站在 CPU 的角度来看count++，这个操作看起来是一行代码，实际上对应到三个CPU指令：

1.load，把内存中的值（count变量）读取到寄存器中

2.add，把指定的寄存器中的值进行+1操作（结果还是在这个寄存器中）

3.save，把寄存器中的值，写回到内存中

CPU执行这三条指令的过程中，随时有可能触发线程的调度切换（如下所示）：

指令1 指令2 指令3 线程切走

指令1  指令2  线程切走  指令3

指令1 线程切走 指令2 指令3

指令1 线程切走 指令2 线程切走 指令3

但是由于操作系统的调度是随机的，不可预期的

执行任何一个指令的过程中都有可能触发上述的“线程切换”的操作

也就是说，随机调度（或者叫抢占式执行）就是线程安全问题的罪魁祸首。

t1线程和t2线程的执行过程可能会出现如下情况（只举了个别例子，可能还有别的情况）：

对于执行结果：打 √ 的为正确结果，× 为错误结果。

对于其中某种正确情况的具体执行过程如下：

对于其中某种错误情况的具体执行过程如下：

可以看到：

t1线程和t2线程分别进行了一次count++操作，理论上count的值应为2，实际上由于随机调度，t1的寄存器和t2的寄存器都读取了内存的初始值0，最终执行完两次count++后count的值为1

由于线程执行的过程中有可能（大概率）会发生上述的错误情况，因此代码的执行结果总是<=100000

如果降低单个线程的循环次数，会发现能运行出正确的结果：

运行结果：

出现这种现象的原因：

事实上，线程安全问题依旧存在，只不过概率变低了。

单个线程执行的count++次数会影响到这个线程的运行时间，即运行50次比运行50000次要快得多

因为运行的太快了，很可能在t2.start()执行之前，t1线程就执行完了

等到后续t2线程的执行，就变成了串行执行

2.3 产生线程安全问题的原因

2.3.1 抢占式执行（根本）

抢占式执行：操作系统对于线程的调度是随机的

抢占式执行策略

最初诞生于多任务操作系统的时候，是非常重大的发明

后世的操作系统，都是一脉相承

2.3.2 多个线程同时修改同一个变量

如果是一个线程，修改一个变量---没问题

如果是多个线程，不是同时修改同一个变量---没问题

如果是多个线程，修改不同变量---没问题（不会出现中间结果相互覆盖的情况）

如果是多个线程，读取同一个变量---没问题（该变量不可修改）

2.3.3 修改操作，不是原子的

原子：

如果一个操作只是对应到一个cpu指令，那么就可以认为它是原子的

cpu就不会出现“一条指令执行到一半”这样的情况

反之，如果一个操作对应到多个cpu指令，那么它就不是原子的，例如：

++

--

+=

-=

........

2.3.4 内容可见性问题

后续再讨论

2.3.5 指令从排序

后续再讨论

2.4 如何解决线程安全问题

2.4.1 抢占式执行

抢占式执行是操作系统的底层设定，程序员无法左右。

2.4.2 多个线程同时修改同一个变量

和代码的结构直接相关

可以调整代码结构，规避一些线程不安全的代码

但是这样的方案不够通用

Java中有个东西：

String 就是采用了“不可变”特性，确保线程安全

2.4.3 修改操作，不是原子的

解决方案

Java中解决线程安全问题，最主要的方案就是：加锁

通过加锁操作，让不是原子的操作，打包成一个原子的操作

计算机中的锁，和生活中的锁，是同样的概念：互斥/排他

把锁“锁上”称为“加锁”

把锁“解开”称为“解锁”

一旦把锁加上了，其他人要想加锁，就得阻塞等待

对于上述例子的count++操作，它并非是原子的，此时就可以使用锁，把刚才不是原子的count++

包裹起来，在count++之前，先加锁，然后进行count++，计算完毕之后，再解锁

（此时在执行三步走的过程中，其他线程就没法“插队”了）

加锁操作，不是把线程锁死到cpu上，禁止这个线程被调度走

而是禁止其他线程重新加这个锁，避免其他线程的操作在当前线程执行的过程中“插队”

加锁：synchronized

加锁 / 解锁 本身是操作系统提供的api

很多编程语言都对这样的api进行了封装

大多数的封装风格，都是采取两个函数：

加锁 lock();

//执行一些要保护起来的逻辑

解锁 unlock();

Java中使用 synchronized 这样的关键字，搭配代码块来实现类似的效果：

synchronized(){ //进入代码块，相当于加锁

//执行一些要保护起来的逻辑

}出了代码块，相当于解锁

使用synchronized对上述案例进行加锁：

可以看到括号内需要填入参数，应该填入什么呢？

填写的是，用来加锁的对象。要 加锁 / 解锁，前提是得先有一个锁

在Java中任何一个对象都可以用作“锁”

这个对象的类型是什么不重要

重要的是，是否有多个线程针对这同一个对象加锁（竞争同一把锁）

再次执行代码，线程安全问题得到了解决：

【注意】

两个线程，针对同一个对象加锁，才会产生互斥效果

（一个线程加上了锁，另一个线程就得阻塞等待，等到第一个线程释放锁，才有机会）

如果是不同的锁对象，此时不会有互斥效果，线程安全问题并没有得到解决：

代码执行结果，依旧存在线程安全问题：

synchronized的变种写法

可以使用 synchronized 修饰方法

这种写法跟之前的写法产生的效果是一样的，执行代码：

修饰方法的写法还能继续变形：使用synchronized修饰方法，就相当于是针对this进行加锁

这种写法跟上面的效果也是一样的。

StringBuffer、Vector这些类里面有些方法就是带有synchronized的：

因此，StringBuffer是线程安全的，而StringBuilder线程不安全。

而方法之中，还有一个特殊情况，static修饰的方法不存在this

此时，synchronized修饰static方法相当于针对类对象加锁：

完

如果哪里有疑问的话欢迎来评论区指出和讨论，如果觉得文章有价值的话就请给我点个关注还有免费的收藏和赞吧，谢谢大家