to meet you Java多线程与并发

 

 

2：

hotspot中对象在内存的布局是分3部分 

1. 对象头
2. 实例数据
3. 对其填充

这里主要讲对象头：通常而言synchronized使用的锁对象是存储在对象头里的，对象头是由Mark Word和Class Metadata Address组成

 

mark word存储自身运行时数据，是实现轻量级锁和偏向锁的关键，默认存储对象的hasCode、分代年龄、锁类型、锁标志位等信息。

因为对象头的信息是与对象定义的数据没有关系的额外存储成本，因此考虑到jvm的空间效率，mark word 被设计出一个非固定的存储结构，以便存储更多有效的数据，它会根据对象自己的状态复用本身的存储空间（轻量级锁和偏向锁是java6后对synchronized优化后新增长的）

Monitor：每一个Java对象天生就自带了一把看不见的锁，它叫内部锁或者Monitor锁（监视器锁）。上图的重量级锁的指针指向的就是Monitor的起始地址。

每一个对象都存在一个Monitor与之关联，对象与其Monitor之间的关系存在多种实现方式，如Monitor能够和对象一块儿建立销毁、或当线程获取对象锁时自动生成，当线程获取锁时Monitor处于锁定状态。

Monitor是虚拟机源码里面用C++实现的

源码解读：_WaitSet 和_EntryList就是以前学的等待池和锁池，_owner是指向持有Monitor对象的线程。当多个线程访问同一个对象的同步代码的时候，首先会进入到_EntryList集合里面，当线程获取到对象Monitor后就会进入到_object区域并把_owner设置成当前线程，同时Monitor里面的_count会加一。当调用wait方法会释放当前对象的Monitor，_owner恢复成null，_count减一，同时该线程实例进入_WaitSet集合中等待唤醒。若是当前线程执行完毕也会释放Monitor锁并复位对应变量的值。

接下来是字节码的分析：

package interview.thread;

/**
 * 字节码分析synchronized
 * @Author: cctv
 * @Date: 2019/5/20 13:50
 */
public class SyncBlockAndMethod {
    public void syncsTask() {
        synchronized (this) {
            System.out.println("Hello");
        }
    }

    public synchronized void syncTask() {
        System.out.println("Hello Again");
    }
}

而后控制台输入 javac thread/SyncBlockAndMethod.java

而后反编译 javap -verbose thread/SyncBlockAndMethod.class

先看看syncsTask方法里的同步代码块

从字节码中能够看出 同步代码块 使用的是 monitorenter 和 monitorexit ，当执行monitorenter指令时当前线程讲试图获取对象的锁，当Monitor的count 为0时将获的monitor，并将count设置为1表示取锁成功。若是当前线程以前有这个monitor的持有权它能够重入这个Monnitor。monitorexit指令会释放monitor锁并将计数器设为0。为了保证正常执行monitorenter 和 monitorexit 编译器会自动生成一个异常处理器，该处理器能够处理全部异常。主要保证异常结束时monitorexit（字节码中多了个monitorexit指令的目的）释放monitor锁

ps：重入是从互斥锁的设计上来讲的，当一个线程试图操做一个由其余线程持有的对象锁的临界资源时，将会处于阻塞状态，当一个线程再次请求本身持有对象锁的临界资源时，这种状况属于重入。就像以下状况：hello2也是会输出的，并不会锁住。

再看看syncTask同步方法

解读：这个字节码中没有monitorenter和monitorexit指令而且字节码也比较短，其实方法级的同步是隐式实现的（无需字节码来控制）ACC_SYNCHRONIZED是用来区分一个方法是否同步方法，若是设置了ACC_SYNCHRONIZED执行线程将持有monitor，而后执行方法，不管方法是否正常完成都会释放调monitor，在方法执行期间，其余线程都没法在得到这个monitor。若是同步方法在执行期间抛出异常并且在方法内部没法处理此异常，那么这个monitor将会在异常抛到方法以外时自动释放。

 

java6以前Synchronized效率低下的缘由:

在早期版本Synchronized属于重量级锁，性能低下，由于监视器锁（monitor）是依赖于底层操做系统的的MutexLock实现的。

而操做系统切换线程时须要从用户态转换到核心态，时间较长，开销较大

java6之后Synchronized性能获得了很大提高（hotspot从jvm层面作了较大优化，减小重量级锁的使用）:

1. Adaptive Spinning 自适应自旋
2. Lock Eliminate 锁消除
3. Lock Coarsening 锁粗化
4. Lightweight Locking 轻量级锁
5. Biased Locking偏向锁
6. ……

自旋锁：

• 许多状况下，共享数据的锁定状态持续时间较短，切换线程不值得
• 经过让线程执行while循环等待锁的释放，不让出CPU
• java4就引入了，不过默认是关闭的，java6后默认开启的
• 自旋本质和阻塞状态并不相同，若是锁占用时间很是短，那自旋锁性能会很好
• 缺点：若锁被其余线程长时间占用，会带来许多性能上的开销，由于自旋一直会占用CPU资源且白白消耗掉CPU资源。
• 若是线程超过了限定次数尚未获取到锁，就该使用传统方式挂起线程（能够设置VM的PreBlockSpin参数来更改限定次数）

 

 

自适应自旋锁：（java6引入,jvm对锁的预测会愈来愈精准，jvm也会愈来愈聪明）

1. 自选次数再也不固定
2. 由前一次在同一个锁上的自旋时间及锁拥有者的状态来决定（若是在同一个锁对象上自旋等待刚刚成功获取过锁而且持有锁的线程正在运行中，jvm会认为该锁自旋获取到锁的可能性很大，会自动增长等待时间，相反jvm 若是可能性很小会省掉自旋过程，避免浪费）

锁消除：jvm的另外一种锁优化，更完全的优化

• JIT编译时，对运行上下文进行扫描，去除不可能存在的竞争的锁，消除毫无心义的锁

锁粗化：另外一种极端，锁消除的做用在尽可能小的范围使用锁，而锁粗化则相反，扩大加锁范围。好比加锁出如今循环体中，每次循环都要执行加锁解锁的，如此频繁操做比较消耗性能

• 扩大加锁范围，避免反复的加锁和解锁

synchronized的四种状态

1. 无锁
2. 偏向锁
3. 轻量级锁
4. 重量级锁

锁膨胀方向：无锁->偏向锁->轻量级锁->重量级锁，synchronized会随着竞争状况逐渐升级，如出现了闲置的monitor也会出现锁降级

偏向锁：减小同一个线程获取锁的代价

1. 大多数状况下，锁不存在多线程竞争，老是由同一个线程屡次得到

ps：核心思想就是若是一个线程得到了锁，那么锁就进入偏向模式，此时MarkWord的结构也变成偏向锁结构，当该线程再次请求锁时，无需再作任何同步操做，即获取锁的过程只须要检查MarkWord的锁标记位为偏向锁以及当前线程ID等于MarkWord的ThreadID便可，这样就省去了大量有关锁申请的操做

不适合用于锁竞争比较激烈的多线程场合

轻量级锁：

轻量级锁是由偏向锁升级而来的，偏向锁运行再一个线程进入同步块的状况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁

适用场景：线程交替执行的同步块

若存在同一时间访问同一锁的状况，就会致使轻量级锁膨胀为重量级锁

轻量级锁的加锁过程：

此图来自https://blog.csdn.net/zqz_zqz

1. 在代码进入同步块的时候，若是同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中创建一个名为锁记录（Lock Record）的空间（线程私有的栈帧里），用于存储锁对象目前的Mark Word的拷贝（对象是存在堆中的，因此对象的MarkWord也再堆中），官方称之为 Displaced Mark Word。
2. 拷贝对象头中的Mark Word复制到锁记录中；
3. 拷贝成功后，虚拟机将使用CAS操做尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。若是更新成功，则执行步骤4，不然执行步骤5。
4. 若是这个更新动做成功了，那么这个线程就拥有了该对象的锁，而且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图所示。
5. 若是这个更新操做失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，若是是就说明当前线程已经拥有了这个对象的锁，那就能够直接进入同步块继续执行。不然说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。 而当前线程便尝试使用自旋来获取锁，自旋就是为了避免让线程阻塞，而采用循环去获取锁的过程。 

锁的内存语义

• 当线程释放锁时，java内存模型会把该线程对应的本地内存中的共享变量刷新到主内存中
• 当线程获取锁时，java内存模型会把该线程对应的本地内存置为无效，从而使得被监视器保护的临界区代码必须从主内存中读取共享变量

总结：

 

问：synchronized和ReentrantLock的区别？

ReentrantLock（可重入锁）

• 位于java.util.concurrent.locks包（著名的juc包是由Doug lea大神写的AQS抽象类框架衍生出来的应用）
• 和CountDownLatch、FutureTask、Semaphore同样基于AQS实现
• 可以实现比synchronized更细粒度的控制，如控制fairness
• 调用lock()后，必须调用unlock()释放锁
• 性能未必比synchronized高，而且也是可重入的

ReentrantLock公平性设置

ReentrantLock fairLock = new ReentrantLock(true);

参数为ture时，倾向于将锁赋予等待时间最久的线程

公平锁：获取锁的顺序按前后调用lock方法的顺序（慎用，一般公平性没有想象的那么重要，java默认的调用策略不多会有饥饿状况的发生，与此同时若要保证公平性，会增长额外的开销，致使必定的吞吐量降低）

非公平锁：获取锁的顺序是无序的，synchronized是非公平锁

例子：

package interview.thread;

import java.util.concurrent.locks.ReentrantLock;

/**
 * @Author: cctv
 * @Date: 2019/5/21 11:46
 */
public class ReentrantLockDemo implements Runnable {

    private static ReentrantLock lock = new ReentrantLock(false);

    @Override
    public void run() {
        while (true) {
            lock.lock();
            System.out.println(Thread.currentThread().getName() + " get lock");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                lock.unlock();
            }
        }

    }

    public static void main(String[] args) {
        ReentrantLockDemo rtld = new ReentrantLockDemo();
        Thread t1 = new Thread(rtld);
        Thread t2 = new Thread(rtld);
        t1.start();
        t2.start();
    }
}

公平锁 new ReentrantLock(true);

非公平锁 new ReentrantLock(false);

ReentrantLock将锁对象化

• 判断是否有线程，或者某个特定线程再排队等待获取锁
• 带超时的获取锁尝试
• 感知有没有成功获取锁

是否能将wait\notify\notifyAll对象化

• java.util.concurrent.locks.Condition

总结synchronized和ReentrantLock的区别：

1. synchronized是关键字，ReentrantLock是类
2. ReentrantLock能够对获取锁的等待时间进行设置，避免死锁
3. ReentrantLock能够获取各类锁信息
4. ReentrantLock能够灵活的实现多路通知
5. 机制：synchronized操做MarkWord，ReentrantLock调用Unsafe类的park()方法

 

 

volatile和synchronized的区别

• volatile本质是在告诉jvm当前变量在寄存器（工做内存）中的值是不肯定的，须要从主存中读取； synchronized则是锁定当前变量，只有当前线程能够访问该变量，其余线程被阻塞住。
• volatile仅能使用在变量级别；synchronized则可使用在变量、方法、和类级别的
• volatile仅能实现变量的修改可见性，不能保证原子性；而synchronized则能够保证变量的修改可见性和原子性
• volatile不会形成线程的阻塞；synchronized可能会形成线程的阻塞。
• volatile标记的变量不会被编译器优化；synchronized标记的变量能够被编译器优化

3：CAS（Co'mpare  and Swap）

一种高效实现线程安全性的方法

一、支持原子更新操做、适用于计数器、序列发生器等场景。

二、属于乐观锁机制，号称 lock - free

三、CAS操做失败时由开发者决定是继续尝试，仍是执行别的操做。

 

悲观锁：

 CAS 多数状况下对开发者来讲是透明的。

 

 

在使用CAS 前要考虑ABA 问题 是否影响程序并发的正确性，若是须要解决ABA 问题，改用传统的互斥同步，可能会比原子性更高效。

 

java线程池，利用Exceutors建立不一样的线程池知足不一样场景需求：

1. newSingleThreadExecutor() 建立一个单线程的线程池。这个线程池只有一个线程在工做，也就是至关于单线程串行执行全部任务。若是这个惟一的线程由于异常结束，那么会有一个新的线程来替代它。此线程池保证全部任务的执行顺序按照任务的提交顺序执行。
2. newFixedThreadPool(int nThreads) 建立固定大小的线程池。每次提交一个任务就建立一个线程，直到线程达到线程池的最大大小。线程池的大小一旦达到最大值就会保持不变，若是某个线程由于执行异常而结束，那么线程池会补充一个新线程。
3.  newCachedThreadPool() 建立一个可缓存的线程池。若是线程池的大小超过了处理任务所须要的线程， 那么就会回收部分空闲（默认60秒不执行任务）的线程，当任务数增长时，此线程池又能够智能的添加新线程来处理任务。此线程池不会对线程池大小作限制，线程池大小彻底依赖于操做系统（或者说JVM）可以建立的最大线程大小
   1. 优势就是灵活建立线程，因地制宜，任务少时很省资源。缺点就是可建立的线程上限太大，源代码里是Integer.MAX_VALUE大小，这个数量有点可怕
4. newScheduledThreadPool() 建立一个大小无限的线程池。此线程池支持定时以及周期性执行任务的需求。
5. newWorkStealingPool() jdk8引入的，内部会构建ForkJoinPool，利用working-stealing算法，并行的处理任务，可是不保证处理顺序

Fork/Join框架

• 把大任务分割成若干个小任务并行执行，最终汇总每一个小任务结果后获得大任务的框架
• work-stealing算法：某个线程从其余线程队列里窃取任务来执行

由于分割成若干个小任务由多个线程去执行，就会出现有的线程已经完成任务而有的还未完成任务，已经完成的线程就闲置了，为了提高效率，让已经完成任务的线程去其余线程窃取队列里的任务来执行。为了减小窃取线程对其余线程的竞争，一般会使用双端队列，执行任务的线程从头部拿任务执行，窃取线程是从队列尾部拿任务执行

 

问：为何要使用线程池？

1. 下降资源消耗（经过重复利用已建立的线程来工做，下降建立线程和销毁线程的消耗）
2. 提升线程的可管理性（线程是稀缺资源，若是无限制的建立会不只会消耗系统资源还会下降系统的稳定性，使用线程池能够统一的分配、调优、监控）

 

Executor的框架图

JUC的三个Executor接口

1. Executor：运行新任务的简单接口，将人物提交和任务执行细节解耦
   1. 经过源码看到newCachedThreadPool是返回的ExecutorService newSingleTreadExecutor是返回的FinalizableDelegatedExecutorService  最终都是继承的Executor
   10. 接口Executor只有一个方法就是execute，对于不一样的实现它多是建立一个新线程当即启动，也多是使用已有的线程来运行传入的任务，也多是根据线程池容量或阻塞队列的容量来决定是否将传入的任务放入阻塞队列中或者拒绝接受任务
2. ExecutorService：具有管理执行器和任务生命周期方法，提交任务机制更完善
   1. ExecutorService是Executor的扩展接口 提供了更方便的管理方法 最经常使用的是 shutdown submit
   2. submit参数有Callable、Runnable两种 并返回Future
3. ScheduledExecutorService：支持Future和按期执行任务

ThreadPoolExecutor的构造函数

1. corePoolSize：核心线程数量
2. maximunPoolSize：线程不够用时可以建立的最大线程数
3. workQueue：任务等待队列（当前线程数量大于等于corePoolSize的时候，将任务封装成work放入workQueue中。不一样的队列排队机制不一样）
4. keepAliveTime：线程池维护线程的空闲时间，线程空闲超过这个时间就会被销毁
5. threadFactory：建立新线程，默认使用Executors.defaultThreadFactory()，新建立的线程是同样的优先级、非守护线程

ps：newCachedThreadPool传入的队列是容量为0的SynchronousQueue，（Java 6的并发编程包中的SynchronousQueue是一个没有数据缓冲的BlockingQueue，生产者线程对其的插入操做put必须等待消费者的移除操做take，反过来也同样）

handler：线程池的饱和策略

1. AbortPolicy：直接抛出异常，这是默认策略
2. CallerRunsPolicy： 用调用者所在多线程来执行任务
3. DiscardOldestPolicy：丢弃队列中最靠前的任务，并执行当前任务
4. DiscardPolicy：直接丢弃任务
5. 实现RejectedExecutionHandler接口自定义handler处理

execute方法执行流程以下：

线程池的状态：

1. RUNNING：可以接受新任务，而且也能处理阻塞队列中的任务
2. SHUTDOWN：不能接受新任务，但能够处理存量任务
3. STOP：再也不接受新任务，也不处理存量任务
4. TIDYING：全部任务都已终止，正在进行最后的打扫工做，有效线程数为0
5. TERMINATED：terminated()方法执行完成后进入该状态（该方法什么也不作只是标识）

状态转换图：

工做线程的生命周期：

问：如何选择线程池大小？（没有绝对的算法或规定，是靠经验累计总结出来的）

• CPU密集型：线程数=按照核数或者核数+1（由于若是线程太多会致使过多的上下文切换，致使没必要要的开销）
• I/O密集型：线程数量=CPU核数*（1+平均等待时间/平均工做时间）

• ps：

  阿里编码规范指出：线程池不容许使用Executors去建立，而是经过ThreadPoolExecutor的方式，这样的处理方式让写的同窗更加明确线程池的运行规则，规避资源耗尽的风险。 说明：Executors各个方法的弊端：
  1）newFixedThreadPool和newSingleThreadExecutor:
    主要问题是堆积的请求处理队列可能会耗费很是大的内存，甚至OOM。
  2）newCachedThreadPool和newScheduledThreadPool:
    主要问题是线程数最大数是Integer.MAX_VALUE，可能会建立数量很是多的线程，甚至OOM。

  例子：使用Guava的ThreadFactoryBuilder 

  输出：

  不加剧试的输出是：

  从例子中看出 maxPoolSize + QueueSize < taskNum 就会抛出拒绝异常 若是不catch这个异常程序没法结束（这里重试机制只是个demo，正确的作法是实现RejectedExecutionHandler接口自定义handler处理）