【JavaGuide笔记】2.3 多线程

2020-04-11  本文已影响0人  linyk3

原文：JavaGuide

2.3 多线程

1. 什么是线程和进程

进程

进程是程序的一次执行过程，是系统运行程序的基本单位。进程是动态的，系统运行一个程序，即是一个进程从创建、运行到消亡的过程。
Java中，启动main函数就是启动一个JVM进程，main函数所在的线程就是这个进程中的一个线程，也称主线程。

线程

线程与进程类似，但线程是一个比进程更小的执行单位。一个进程在其执行过程中可以产生多个线程。
与进程不同的是，同个进程的多个线程共享进程的堆和方法区资源。每个线程有自己的程序计数器、虚拟机栈和本地方法栈。
所以系统在产生一个线程、或者在各个线程之间切换时，负担比进程要小。
线程也称为轻量级进程。

2. 进程与线程的关系和区别

JVM中进程和线程的区别


image.png

从上面可以看出，一个进程中可以有多个线程，多个线程共享进程的堆和方法区（JDK1.8之后的元空间）资源。但每个线程有自己的程序计数器、虚拟机栈和本地方法栈。

总结： 线程是进程划分为更小的运行单位。各进程是独立的，但一个进程中的各个线程，是共享部分资源的。

为什么程序计数器是私有的：

注意：如果执行的是native方法，程序计数器记录的是undefined 地址，只有执行的是Java代码时，程序计数器记录的才是下一条指令的地址。
所以，程序计数器私有主要是为了线程切换后能恢复到正确的执行位置。

为什么虚拟机栈和本地方法栈是私有的

所以，为了保证线程中的变量不被别的线程访问，虚拟机栈和本地方法栈是线程私有的。

一句话了解堆和方法区

堆和方法区是所有线程共享的资源。

3. 并发 VS 并行

4. 为什么使用多线程

总体原因：

5. 多线程可能带来的问题

并发编程的目的是为了提高程序的执行效率，提高运行速度，但并发编程并不总是能达到目的的，还会遇到很多问题，例如：内存泄漏、上下文切换、死锁以及受限于硬件和软件资源闲置的问题。

6.线程的生命周期和状态

Java线程在运行的生命周期中的指定时刻只能处于下面6中不同状态的其中一个状态：

状态名称 说明
new 初始状态，线程被构建，但是还没有调用start()方法
runnable 运行状态，Java线程将操作系统中的就绪和运行两种状态统称为“运行中”
blocked 阻塞状态，表示线程阻塞于锁
wating 等待状态，表示线程进入等待状态，进入该状态表示当前线程需要等待其他线程做出一些特定动作（通知或中断）
time_wating 超时等待状态，该状态不同于waiting，他是可以在指定时间内自行返回的。
terminated 终止状态，表示当前线程已经执行完毕
image.png

7. 上下文切换

多线程编程中一般线程的个数都大于CPU的核心数，而一个CPU核心在任意时刻都是能被一个线程使用，为了让这些线程都能得到有效的执行，CPU采用的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。
概括来说就是：当前任务在执行完CPU时间片切换到另一个任务之前，会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。
因此，上下文切换对系统来说就是意味着消耗大量的CPU时间，事实上，可能是操作系统中时间消耗最大的操作。

Linux 相对其他操作系统（包括其他类Unix系统）的一个优点就是其上下文切换和模式切换的时间耗时非常少。

8. 线程死锁

认识线程死锁

多个线程同时被阻塞，他们中的一个或者全部都在等待某个资源被释放。由于线程被无限期的阻塞，因此程序不能正常终止。

image.png
发生死锁的4个条件
解决死锁问题

只要破坏产生死锁的4个条件之一即可。

9. sleep() VS wait()

10. start() VS run()

正常启动一个线程，首先需要new一个Thread，然后线程进入新建状态，调用 start() 后，会启动线程并使线程进入就绪状态，当分配到时间片后就可以执行了。start()会执行线程的相应准备工作，然后自动执行run() 方法，这才是真正的多线程工作。
如果直接执行run() 方法，相当于把run() 方法当做main线程下的普通方法去执行，并不会在某个线程中执行它。

总结：
调用start() 方法可以启动线程并使线程进入就绪状态。而run()方法只是thread 的一个普通方法调用。

10. synchronized 关键字

synchronized 关键字解决的是多个线程之间访问资源的同步性，synchronized 关键字可以保证它被修饰的方法或者代码块在任意时刻只能有一个线程执行。

早期Java 版本中，synchronized 属于重量级锁，效率低下，因为synchronized 采用的监视器锁（monitor）是依赖于底层操作系统的Mutex Lock实现，所有要挂起或唤醒一个线程，都需要操作系统来帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，需要消耗较长的时间。
Java 6之后，Java 官方从JVM层面对synchronized进行了较大的优化，现在锁效率已经很不错了。
JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

synchronized 的三种用法

总结：synchronized 关键字加到static 静态方法和synchronized(class) 代码块 都是给class 类加锁。
synchronized 关键字加到实例方法上是给对象实例加锁。
尽量不要使用 synchronized(String a), 因为在JVM中，字符串常具有缓存功能。

双重校验锁实现对象单例（线程安全）

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 uniqueInstace;
    }
}

其中注意uniqueInstance 需要 volatile 关键字修饰。因为 uniqueInstance = new Singleton() 这句代码是分为三步执行的：

JVM具有指令重排的特性，执行顺序有可能变成 1 => 3 => 2.
如果thread1 执行了1和3， thread2 刚好执行了getUniqueInstance() 后发现uniqueInstance 不为空，直接返回还未被初始化的uniqueInstance，导致出问题。

指令重排在单线程不会出现问题，但多线程会导致一个线程获得还没有初始化的实例。使用volatile可以禁止JVM的指令重排，保证在多线程环境下也能正常运行。

synchronized 关键字底层原理
synchronized 同步语句块
public class SynchronizedDemo {
    public void method() {
        synchronized(this) {
            System.out.println("synchronized 代码块");
        }
    }
}
image.png

synchronized 同步语句块，在底层是通过JVM来实现的，具体是通过monitorenter 和 monitorexit指令。当执行monitorenter指令时，线程试图获取锁，也就是获取每个Java对象的对象头中的monitor对象。这也是Java中的任意对象能作为锁的原因。
当monitor的计数器为0时，说明可以成功获取，获取后将其+1，执行完成后，在 monitorexit 指令中将锁计数设为0，将锁释放。
如果获取monitor对象锁失败，那么当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

synchronized 修饰方法
public class SynchronizedDemo2 {
    public synchronized void method() {
        System.out.println("synchronized 方法");
    }
}
image.png

synchronized 修饰的方法并没有使用 monitorenter 和 monitorexit 指令，而是采用ACC_SYNCHRONIZED 标识，其表明该方法是一个同步方法，JVM 通过该ACC_SYNCHRONIZED 访问标志来辨别一个方法是否是同步方法，从而执行相应的同步调用。

锁主要存在4种状态：

JDK1.6 对synchronized 的优化

引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。

偏向锁

在没有多线程竞争的前提下，为了减少传统的重量级锁（使用操作系统互斥量）产生的性能消耗，偏向锁会在无竞争情况下就把整个同步都消除掉。偏向锁会偏向第一个获取它的线程，如果接下来的执行中，如果该锁没有被其他线程获取，那么持有偏向锁的线程就不需要进行同步。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样的场合极有可能每次申请锁的线程都是不相同的，所有这种情况下不应该使用偏向锁。不过，偏向锁失败后，不会直接膨胀为重量级锁，而是先升级为轻量级锁。

轻量级锁

在没有多线程竞争的前提下，为了减少传统的重量级锁（使用操作系统互斥量）产生的性能消耗，轻量级所会在无竞争的情况下使用CAS操作去代替使用互斥量。但如果存在锁竞争，除了互斥量开销外，还会额外产生CAS操作，性能更慢。如果锁竞争激烈，那么轻量级锁将很快膨胀为重量级锁。

自旋锁和自适应自旋锁

一般线程持有锁的时间都不是太长，所以仅仅为了这一点点时间去挂起/恢复线程是得不偿失的。所以JVM尝试让后面来请求锁的线程等待一会而不被挂起，看看持有锁的线程是否很快就释放锁。为了让一个线程等待，我们只需要让一个线程执行一个忙循环（自旋），这种操作就成为自旋锁。JDK1.6 引入的是自适应自旋锁，它自旋的时间不在固定，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定等待时间。

锁消除

JVM在编译时，检测到不存在竞争的共享数据，就执行锁消除操作，从而节省毫无意义的请求锁的时间

锁粗化

原则上，在编写代码的时候将同步块的作用范围限制得尽量小：在共享数据的实际作用域才进行同步，这样使得需要同步的操作数量尽可能变小。
不过，上面是适合大部分情况的，但如果一系列的连续操作都是对同一个对象反复加锁和解锁，那么会带来很多不必要的性能消耗，这时就会执行锁粗化操作。

image.png
synchronized 和 ReenTrantLock 对比
上一篇 下一篇

猜你喜欢

热点阅读