Java复习笔记之并发

进程和线程的区别

进程和线程的由来

  

  

进程和线程的区别

  进程是资源分配的最小单位，线程是CPU调度的最小单位

     所有与进程相关的资源，都被记录在PCB中

    进程是抢占处理机的调度单位，线程属于某个进程，共享其资源

    线程只由堆栈寄存器，程序计数器和TCB（线程控制块）组成

 总结：

线程不能看做独立应用，而进程可看做独立应用

进程有独立的地址空间，相互不影响，线程只是进程的不同执行路径

线程没有独立的地址空间，多进程的程序比多线程程序更加健壮

线程的切换开销比进程的大

Java进程和线程的关系

  java对操作系统提供的功能进行封装，包括进程和线程

  运行一个程序会产生一个进程，进程包含至少一个线程

  每个进程对应一个JVM实例，多个线程共享JVM里的堆

  java采用单线程编程模型，程序会自动创建主线程

 主线程可以创建子线程，原则上要后于子线程完成执行

 

Thread中的start和run方法的区别

 

调用start()方法会创建一个新的子线程并启动

run()方法只是Thread的一个普通方法的调用

 

Thread和Runnable是什么关系？

  Thread是实现了Runnable接口的类，使得run支持多线程

  因类的的单一继承原则，推荐多使用Runnable接口

 

如何给run()方法传参

  实现的方式主要有三种

     构造函数传参

     成员变量传参

     回调函数传参

 

如何实现处理线程的返回值

 实现的方式主要有三种；

   主线程等待法：在主线程中执行循环等待逻辑，sleep（）方法等待

     t.start(); while(cw.value == null){ Thread.currentThread().sleep(100);}

 使用Thread类的join()阻塞当前线程以等待子线程处理完毕

     t.join()

   通过Callable接口实现：通过FutureTask Or 线程池获取

 

 

线程的状态

   六个状态

1. 新建（New): 创建后尚未启动的线程的状态
2. 运行(Runnable):包含Running和Ready
3. 无限期等待（Waiting):不会被分配CPU执行时间，需要显示被唤醒

   没有设置Timeout参数的Object.wait()方法

   没有设置Timeout参数的Thread.join()方法

   L ockSupport.park()方法

1. 限期等待（Timed Waiting): 在一定时间后会由系统自动唤醒

        Thread.sleep()方法

        设置了Timeout参数的Object.wait()方法

        设置了Timeout参数的Thread.join()方法

        LockSupport.parkNanos()方法

        LockSupport.parkUntil()方法

1. 阻塞（Blocked): 等待获取排它锁
2. 结束（Terminated): 已终止线程的状态，线程已经结束

 

Sleep和Wait的区别

基本的差别：

   Sleep是Thread类的方法，Wait是Object类中定义的方法

   Sleep()方法可以在任何地方使用，wait()方法只能在synchronized方法或synchronized块中使用

最主要的本质区别：

Thread.sleep只会让出CPU，不会导致锁行为的改变

Object.wait不仅让出CPU，还会释放已经占有的同步资源锁

 

notify和notifyAll的区别

两个概念：

  锁池EntryList

     假设线程A已经拥有了某个对象（不是类）的锁，而其他线程B，C想要调用这个对象的某个synchronized方法（或者块），由于B，C线程在进入对象的synchronized方法（或者块）之前必须先获得该对象锁的拥有权，而恰巧该对象的锁目前正被线程A所占用，此时B，C线程就会被阻塞，进入一个地方去等待锁的释放，这个地方便是该对象的锁池

 

等待池WaitSet

 假设线程A调用了某个对象的wait()方法，线程A就会释放该对象的锁，同时线程A就进入到该对象的等待池中，进入到等待池中的线程不会竞争该对象的锁。

 

区别：

   notifyAll会让所有处于等待池的线程全部进入锁池去竞争获取锁的机会

   notify只会随机选取一个处于等待池中的线程进入锁池去竞争获取锁的机会

 

Yield

概念

  当调用Thread.yield()函数时，会给线程调度器一个当前线程愿意让出CPU使用的暗示，但是线程调度器可能会忽略这个暗示

 

如何中断线程？

已经被抛弃的方法

  通过调用stop()方法停止线程

  通过调用suspend()和resume()方法

目前使用的方法

  调用interrupt(), 通知线程应该中断了

如果线程处于被阻塞状态，那么线程将会立即退出被阻塞状态，并抛出一个InterruptedException异常

如果线程处于正常活动状态，那么会将该线程的中断标志设置为true。被设置中断标志的线程将继续正常运行，不受影响。

  需要被调用的线程配合中断

在正常运行任务时，经常检查本线程的中断标志位，如果被设置了中断标志就自行停止线程

如果线程处于正常活动状态，那么会将该线程的中断标志设置为true。被设置中断标志的线程将继续正常运行，不受影响。

线程状态以及状态之间的转换

  

 

Synchronized

线程安全问题的主要诱因

   存在共享数据（也称临界资源）

   存在多条线程共同操作这些共享数据

解决问题的根本方法：

  同一时刻有且只有一个线程在操作共享数据，其他线程必须等到该线程处理完数据后再对共享数据进行操作

 

互斥锁的特性

  互斥性：即在同一时间只允许一个线程持有某个对象锁，通过这种特性来实现多线程的协调机制，这样同一个时间只有一个线程对需要同步的代码块（复合操作）进行访问。互斥性也称为操作的原子性。

  可见性：必须确保在锁被释放之前，对共享变量所做的修改，对于随后获得该锁的另一个线程是可见的（即在获得锁时应获得最新共享变量的值），否则另一个线程可能是在本地缓存的某个副本上继续操作，从而引起不一致。

 Synchronized锁的不是代码，锁的都是对象

 

根据获取锁的分类：获取对象锁和获取类锁

获取对象锁的两种用法（如果锁住的是不同的对象，则执行后是异步结果）

1. 同步代码块（synchronized(this), synchronized(类实例对象））,锁是小括号中的实例对象。
2. 同步非静态代码块（synchronized method), 锁是当前对象的实例对象。

获取类锁的两种用法（如果锁住的是一个类的不同实例，则因为锁住的是同一个类，还是同步结果）

1. 同步代码块（synchronized(类.class)), 锁的是小括号()中的类对象(class对象）
2. 同步静态方法(synchronized static method), 锁的是当前对象的类对象(Class对象）

 

对对象锁和类锁的总结

1. 有线程访问对象的同步代码块时，另外的线程可以访问该对象的非同步代码块
2. 若锁住的是同一个对象，一个线程在访问对象的同步代码块时，另一个访问对象的同步代码块的线程会被阻塞
3. 若锁住的是同一个对象，一个线程在访问对象的同步方法时，另一个访问对象同步方法的线程会被阻塞；
4. 若锁住的是同一个对象，一个线程在访问对象的同步代码块时，另一个访问对象同步方法的线程会被阻塞，反之亦然。
5. 类锁由于也是一种特殊的对象锁，因此表现和上述1，2，3，4一致，而由于一个类只有一把对象锁，所以同一个类的不同对象使用类锁将会是同步的；
6. 类锁和对象锁互不干扰。

 

Synchronized底层实现原理

  实现synchronized的基础

Java对象头

Monitor

对象在内存中的布局

对象头

实例数据

对齐填充

 

 

  什么是重入

   从互斥锁的设计来说，当一个线程试图操作一个由其他线程持有的对象锁的临界资源时，将会处于阻塞状态，但当一个线程再次请求自己持有对象锁的临界资源时，这种情况属于重入。

 

为什么会对synchronized嗤之以鼻

  早期的版本中，synchronized属于重量级锁，依赖于Mutex Lock实现

  线程之间的切换需要从用户态转换到核心态，开销较大

Java6以后，synchronized性能得到了很大的提升

  Adaptive Spinning:自适应自旋

  Lock Eliminate：锁消除

  Lock Coarsening：锁粗化

  Lightweight Locking：轻量级锁

  Biased Locking：偏向锁

 

自旋锁和自适应自旋锁

自旋锁：PreBlockSpin

  许多情况下，共享数据的锁定状态持续时间较短，切换线程不值得

  通过让线程执行忙循环等待锁的释放，不让出CPU

  缺点：若锁被其他线程长时间占用，会带来许多性能上的开销

自适应自旋锁

  自旋的次数不再固定

  由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定

 

锁消除

更彻底的优化

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

 

锁粗化

另一种极端：通过扩大加锁的范围，避免反复加锁和解锁

 

synchronized的四种状态

无锁，偏向锁，轻量级锁，重量级锁

锁膨胀方向：无锁——> 偏向锁——>轻量级锁——>重量级锁

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

  大多数情况下，锁不存在多线程竞争，总是由同一个线程多次获得

核心思想：

 如果一个线程获得了锁，那么锁就进入偏向模式，此时mark world的结构也变为偏向锁结构，当该线程再次请求锁时，无需再做任何同步操作，即获取锁的过程只需要检查Mark World的锁标记为偏向锁以及当前线程Id等于Mark World的ThreadID即可，这样就省去了大量有关锁申请的操作。 但不适用于锁竞争比较激烈的多线程场合

 

轻量级锁

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

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

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

 

锁的内存语义

 当线程释放锁时，java内存模型会把该线程对应的本地内存中的共享变量刷新到主内存中

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

 

偏向锁，轻量级锁，重量级锁的汇总

锁	优点	缺点	使用场景
偏向锁	加锁和解锁不需要CAS操作，没有额外的性能消耗，和执行非同步方法相比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁撤销的消耗	只有一个线程访问同步块或者同步方法的场景
轻量级锁	竞争的线程不会阻塞，提高了响应速度	若线程长时间抢不到锁，自旋会消耗CPU性能	线程交替执行同步块或者同步方法的场景
重量级锁	线程竞争不使用自旋，不会消耗CPU	线程阻塞，响应时间缓慢，在多线程下，频繁的获取和释放锁，会带来巨大的性能消耗	追求吞吐量，同步块或者同步方法执行时间较长的场景

 

Synchronized和ReentrantLock的区别

ReentrantLock(再入锁）

  位于java.util.concurrent.locks包

  和CountDownLatch, FutureTask, Semaphore一样基于AQS实现

  能够实现比synchronized更细粒度的控制，如控制fairness

  调用lock()之后，必须调用unlock()释放锁  

  性能未必比synchronized高，并且也是可重入的

 

ReentrantLock公平性的设置

  ReentrantLock fairLock = new ReentrantLock(true);

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

  公平锁：获取锁的顺序按先后调用lock方法的顺序（慎用）

  非公平锁：抢占的顺序不一定，看运气  

  synchronized是非公平锁

 

ReentrantLock将锁对象化

   判断是否有线程，或者某个特定线程，在排队等待获取锁

   带超时的获取锁的尝试

   感知有没有成功获取锁

将wait\notify\notifyAll对象化

  Java.util.concurrent.locks.Condition

 

总结：

  synchronized是关键字，ReentrantLock是类

  ReentrantLock可以对获取锁的等待时间进行设置，避免死锁

  ReentrantLock可以获取各种锁的信息

  ReentrantLock可以灵活地实现多路通知

  机制：sync操作Mark World, lock调用Unsafe类的park()方法

 

什么是java内存的模型中的happens-before

Java内存模型JMM

   Java内存模型（即java Memory Model, 简称JMM）本身是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式

JMM中的主内存和工作内存

JMM中的主内存

   存储Java实例对象

   包括成员变量，类信息，常量，静态变量等

   属于数据共享的区域，多线程并发操作时会引发线程安全问题

 JMM中工作内存

存储当前方法的所有本地变量信息，本地变量对其他线程不可见

字节码行号指示器，Native方法信息

属于线程私有数据区域，不存在线程安全问题

 

JMM与Java内存区域划分是不同的概念层次

   JMM描述的是一组规则，围绕原子性，有序性，可见性展开

   相似点：存在共享区域和私有区域

 

主内存与工作内存的数据存储类型以及操作方式归纳   

   方法里的基本数据类型的本地变量将直接存储在工作内存的栈帧结构中

   引用类型的本地变量；引用存储在工作内存中，实例存储在主内存中

   成员变量，static变量，类信息均会被存储在主内存中

   主内存共享的方式是线程各拷贝一份数据到工作内存，操作完成后刷新回主内存

 

JMM如何解决可见性问题

指令重排序需要满足的条件

   在单线程环境下不能改变程序运行的结果

   存在数据依赖关系的不允许重排序

 即无法通过happens-before原则推导出来的，才能进行指令的重排序

 

A操作的结果需要对的B操作可见，则A与B存在happens-before关系

happens-before的八大原则

1. 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
2. 锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作
3. volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作
4. 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C
5. 线程启动规则：Thread对象的start（）方法先行发生于此线程的每一个动作
6. 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
7. 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束，Thread.isAlive()的返回值手段检测到线程已经终止执行
8. 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

 

Happens-before的概念

  如果两个操作不满足上述任意一个happens-before规则，那么这两个操作就没有顺序的保障，JVM可以对这两个操作进行重排序；

  如果操作A happens-before操作B，那么操作A在内存上所做的操作，对操作B都是可见的。

 

Volatile:JVM提供的轻量级同步机制

   保证被volatile修饰的共享变量对所有线程总是可见的

   禁止指令重排序优化  

  （对volatile变量的运算操作并不保证可见性）

 

volatile变量为何立即可见？

 当写一个volatile变量时，JMM会把该线程对应的工作内存中共享变量值刷新到主内存中；

 当读取一个volatile变量时，JMM会把该线程对应的工作内存置为无效，直接从主内存中读取

 

volatile如何禁止重排序优化

   内存屏障(Memory Barries)   

1. 保证特定操作的执行顺序
2. 保证某些变量的内存可见性

  通过插入内存屏障指令禁止在内存屏障前后的指令执行重排序优化

  强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本

 

单例的双重检测实现

Volatile和synchronized的区别

1. volatile本质是在告诉JVM当前变量的寄存器（工作内存）中的值是不确定的，需要从主内存中读取；synchronized则是锁住当前变量，只有当前线程可以访问该变量，其他线程被阻塞住直到该线程完成变量操作为止
2. volatile仅能使用在变量级别；synchronized则可以使用在变量，方法和类级别
3. volatile仅能实现变量的修改可见性，不能保证变量的原子性。而synchronized则可以保证变量修改的可见性和原子性
4. volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞
5. volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化

 

CAS(Compare and Swap)

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

  支持原子更新操作，适用于计数器，序列发生器等场景

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

  CAS操作失败时由开发者决定是否继续尝试，还是执行别的操作

 

CAS思想

 包含三个操作数——内存位置（V）， 预期原值（A）和新值（B）

 

CAS多数情况下对开发者来说都是透明的

1. U.C的atomic包提供了常用的原子性数据类型以及引用，数组等相关原子类型和更新操作工具，是很多线程安全程序的首选

Unsafe类虽提供CAS服务，但因能够操纵任意内存地址读写而有隐患

Java9以后，可以使用variable Handle API来替代Unsafe

 

缺点

  若循环时间长，则开销很大

  只能保证一个共享变量的原子操作

  ABA问题（A改B， B又改A）解决：AtomicStampedReference

 

Java线程池

  利用Executors创建不同的线程池满足不同场景的需求

1.newFixedThreadPool(int nThreads)

  指定工作线程数量的线程池

2.newCachedThreadPool()

 处理大量短时间工作任务的线程池

1. 试图缓存线程并重用，当无缓存线程可用时，就会创建新的工作线程
2. 如果线程闲置的时间超过阈值，则会被终止并移出缓存
3. 系统长时间闲置的时候，不会消耗什么资源

3.newSingleThreadExecutor()

 创建唯一的工作者线程来执行任务，如果线程异常结束，会有另一个线程取代它

4.newSingleThreadScheduledExecutor()与newScheduledThreadPool(int corePoolSize)

定时或者周期性的工作调度，两者的区别在于单一工作线程还是多线程

5.newWorkStealingPool()

内部会构建ForkJoinPool,利用working-stealing算法，并行地处理任务，不保证处理顺序

 

Fork/Join框架

  把大任务分割成若干个小任务并行执行，最终汇总每个小任务结果后得到大任务结果的框架。

working-stealing算法：某个线程从其他队列里窃取任务来执行

 

为什么要使用线程池？

  降低资源的消耗

  提高线程的可管理性

 

Executor的框架

  

1. U.C的三个Executor接口

 Executor:运行新任务的简单接口，将任务提交和任务执行细节解耦

 ExecutorService: 具备管理执行器和任务生命周期的方法，提交任务机制更完善

 ScheduleExecutorSevice:支持Future和定期执行任务

 

ThreadPoolExecutor

 

 

ThreadPoolExecutor的构造函数

  corePoolSize: 核心线程数量

  maximumPoolSize:线程不够用时能够创建的最大线程数

  workQueue:任务等待队列

  keepAliveTime:抢占的顺序不一定，看运气

  threadFactory:创建新线程，Executors.defaultThreadFactory()

  Handler: 线程池的饱和策略

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

 

新任务提交execute执行后判断

1. 如果运行的线程少于corePoolSize,则创建新线程来处理任务，即使线程池中的其他线程是空闲的
2. 如果线程池中的线程数量大于等于corePoolSize且小于maximumPoolSize,则只有当workQueue满时才创建新的线程去处理任务
3. 如果设置的corePoolSize和maximumPoolSize相同，则创建的线程池的大小是固定的，这时如果有新任务提交，若workQueue未满，则将请求放入workQueue中，等待有空闲的线程去从workQueue未满，则将请求放入workQueue中，等待有空闲的线程去从workQueue中取任务并处理
4. 如果运行的线程数量大于maximumPoolSize, 这时如果workQueue已经满了，则通过handler所指定的策略来处理任务

 

Java线程池流程图

  

线程池的状态

1. RUNNING: 能够接受新提交的任务，并且也能处理阻塞队列中的任务
2. SHUTDOWN：不再接受新提交的任务，但可以处理存量任务
3. STOP:不再接受新提交的任务，也不处理存量任务
4. TIDYING:所有的任务都已终止
5. TERMINATED:terminated()方法执行完后进入该状态

 

线程的状态转换图

 

工作线程的生命周期

线程池的大小如何选定

  CPU密集型：线程数 = 按照核数或者核数+ 1设定

   I/O密集型：线程数 = CPU核数 * （1 + 平均等待时间/平均工作时间）