多线程 一
一．概念进程与线程
程序由指令和数据组成，但这些指令要运行，数据要读写，就必须要把程序加载到CPU内存，这就开启了一个进程
一个进程之内可以分为多个线程，一个线程就是一个指令流，将指令流终端一条条指令以一定的顺序交给CPU执行，进程是不活动的，只是作为线程的容器
进程基本上相互独立，进程拥有共享的资源，如内存空间，供内部的线程共享
不同计算机的进程通信，需要通过网络，遵守共同的协议，如HTTP
线程通信相对简单，因为共享了进程内的内存
线程上下文切换成本比进程上下文切换成本低
并行和并发
并发 是一个CPU通过任务调度器，将cpu的时间片分配给不同的线程使用，相当于轮流去执行多个指令，微观串行，宏观并行
并行 是多核CPU同一时间点多个核心同时执行多个指令
多线程应用
不需要等待结果返回，就能继续运行就是异步
开启异步调用，就是开启多线程来运行，提高用户体验
如果四核cpu分别使用核心去执行线程1，2，3，4，这样花费的时间就只是线程最长的运行时间，提高效率，并行
如果是单核cpu，即使用了多线程，微观上还是串行运行，不会提高效率，并发
单核cpu下，多线程不能实际提高程序运行效率，但是可以让不同的线程轮流使用cpu，不至于一个线程总占用cpu，别的线程没法干活
Slf4j的使用
1引入依赖包
org.projectlomboklombok1.18.0 org.slf4jslf4j-api1.7.25 ch.qos.logbacklogback-classic1.2.3 org.junit.jupiterjunit-jupiter-api5.2.0test2加入lombok插件
3测试代码
二．Java线程
创建线程
1 直接使用Thread
@Slf4j(topic="c.Test")
public class Test1 {
public static void main(String[] args) {
Thread t = new Thread(){
@Override
public void run() {
log.debug("Thread running");
}
};
t.setName("t1");
t.start();
log.debug("Main running");
}
}
2使用Runnable配合Thread
@Slf4j(topic="c.Test")
public class Test2 {
public static void main(String[] args) {
Runnable runnable = new Runnable() {
@Override
public void run() {
log.debug("running");
}
};
Thread t = new Thread(runnable,"t2");
t.start();
log.debug("Main running");
}
}
3 lambda简化
对比上面的正常设置，比较简便，能简化成lambda的一般是接口类只有一个实现方法，并且接口类含有@FunctionalInterface注解
4实现RunnableFuture接口配合Thread
//RunnableFuture
FutureTask<Integer> task = new FutureTask(new Callable() {
@Override
public Object call() throws Exception {
log.debug("running");
Thread.sleep(1000);
return 100;
}
});
Thread t2 = new Thread(task,"t2"); //传进设置好的参数对象
t2.start();
log.debug("{}",task.get()); //阻塞获取结果的返回
原理：
方法1是重写了父类Thread的run方法
方法2是把runnable的参数传给了Thread的构造方法，然后里面的run方法实现调用了传进来 的runnable的run方法
方法4有返回值，可以实现线程间互相传值，达到线程间通信的功能
小结：
方法1是把线程和任务合并在一起，方法2是把线程和任务分开了
用runnable更容易与线程池等高级API配合
用Runnable让任务类脱离了Thread继承体系，更灵活
线程运行
两个线程同时运行，底层运行是一个CPU去并发执行，还是多核CPU去并行执行，是由底层的任务调度器决定的，我们不能判断出来
查看杀死进程
| Window | jps | taskkill /F /PID 进程号 |
| Linux | Ps -ef /grep java | kill -9 进程号 |
| Java进程 | jconsole | 图形化界面查看进程 |
线程运行原理
Java线程运行加载过程：
多线程：
每个线程有自己的一个独立的栈
线程上下文切换
因为以下一些原因导致 cpu 不再执行当前的线程，转而执行另一个线程的代码
被动原因：
线程的 cpu 时间片用完(每个线程轮流执行，看前面并行的概念)
垃圾回收
有更高优先级的线程需要运行
主动原因：
线程自己调用了 sleep、yield、wait、join、park、synchronized、lock 等方法
当 Context Switch 发生时，需要由操作系统保存当前线程的状态，并恢复另一个线程的状态，Java 中对应的概念 就是程序计数器（Program Counter Register），它的作用是记住下一条 jvm 指令的执行地址，是线程私有的。
常见方法
start() 启动一个新线程，在新线程中运行 run 方法中的代码 start 方法只是让线程进入就绪状态，里面代码不一定立刻运行，只有当 CPU 将时间片分给线程时，才能进入运行状态，执行代码。每个线程的 start 方法只能调用一次，调用多次就会出现 IllegalThreadStateException
run() 新线程启动会调用的方法 如果在构造 Thread 对象时传递了 Runnable 参数，则线程启动后会调用 Runnable 中的 run 方法，否则默认不执行任何操作。但可以创建 Thread 的子类对象，来覆盖默认行为
join() 等待线程运行结束
join(long n) 等待线程运行结束,最多等待 n 毫秒
getId() 获取线程长整型的 id id 唯一
getName() 获取线程名
setName(String) 修改线程名
getPriority() 获取线程优先级
setPriority(int) 修改线程优先级 java中规定线程优先级是1~10 的整数，较大的优先级能提高该线程被 CPU 调度的机率
getState() 获取线程状态 Java 中线程状态是用 6 个 enum 表示，分别为：NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED
isInterrupted() 判断是否被打断 不会清除 打断标记
isAlive() 线程是否存活（还没有运行完毕）
interrupt() 打断线程 如果被打断线程正在 sleep，wait，join 会导致被打断的线程抛出 InterruptedException，并清除 打断标记 ；如果打断的正在运行的线程，则会设置 打断标记，park 的线程被打断，也会设置 打断标记
interrupted() static 判断当前线程是否被打断 会清除 打断标记
currentThread() static 获取当前正在执行的线程
sleep(long n) static 让当前执行的线程休眠n毫秒，休眠时让出 cpu 的时间片给其它线程
yield() static 提示线程调度器让出当前线程对CPU的使用 主要是为了测试和调试
1.start() VS run()
直接调用线程的run方法，虽然会创建了线程，但是执行的是main线程去调用，这个线程对象会处一直处在新建状态
调用线程的start方法，则执行的是CPU 会为创建的线程分配时间片来创建子线程，并且由子线程去调用执行任务
2.sleep()与yield()
sleep (使线程阻塞)
调用 sleep 会让当前线程从 Running 进入 Timed Waiting 状态（阻塞）
其它线程可以使用 interrupt 方法打断正在睡眠的线程，这时 sleep 方法会抛出 InterruptedException
睡眠结束后的线程未必会立刻得到执行，可能CPU还在被占用
建议用 TimeUnit 的 sleep 代替 Thread 的 sleep 来获得更好的可读性
yield （让出当前线程）
调用 yield 会让当前线程从 Running 进入 Runnable 就绪状态（仍然有可能被执行），让出CPU的使用权，然后调度执行其它线程
具体的实现依赖于操作系统的任务调度器
小结：
sleep和yield的区别是 sleep是让线程进入一段时间阻塞，任务调度器是不会分配时间片给这种阻塞线程，而会考虑分配给yield后的就绪状态的线程，sleep是有一段等待时间，而yield是几乎没有等待时间的
**Sleep的小应用：**如果是单核cpu下运行一个死循环线程，则会造成CPU占用率99%，这是我们如果在循环里面加入sleep（50），则会大大降低cpu的占占用率，可以降到3%左右
线程优先级
线程优先级会提示（hint）调度器优先调度该线程，但它仅仅是一个提示，任务调度器可以忽略它，不一定要听优先级的
如果 cpu 比较忙，那么优先级高的线程会获得更多的时间片，但 cpu 闲时，优先级几乎没作用
不管是yield或者是线程优先级，它们都不能决定CPU调用线程的先后，决定者还是任务调度器
3）join() 方法
用于等待某个线程结束。哪个线程内调用join()方法，就等待哪个线程结束，然后再去执行其他线程。
如在主线程中调用ti.join()，则是主线程等待t1线程结束，join 采用同步。
需要等待结果返回，才能继续运行的就是同步
不需要等待结果返回，就能继续运行的就是异步
有时效的join：
t1.join（2000）如果线程提前结束了，那也会以实际线程结束的时间为准，如果线程运行需要3秒，则不会执行完毕，2秒即退出返回主线程
4）interrupt() 方法
interrupt 打断线程有两种情况，如下：
如果一个线程在在运行中被打断，打断标记会被置为 true 。
如果是打断因sleep wait join 方法而被阻塞的线程，会将打断标记置为 false
isInterrupted() 与 interrupted() 比较
Interrupted查看线程打断状态后，会将打断标志置为false，也就是清空打断标记
终止模式之两阶段终止模式，如下：
考虑在一个线程T1中如何优雅地终止另一个线程T2？这里的优雅指的是给T2一个料理后事的机会
@Slf4j(topic = "c.TwoParseTermination")
class TwoParseTermination {
private Thread monitor;
// 启动线程
public void start() {
monitor = new Thread(() -> {
while (true) {
Thread thread = Thread.currentThread();
if(thread.isInterrupted()) { // 调用 isInterrupted 不会清除标记
log.info("料理后事 ...");
break;
} else {
try {
Thread.sleep(1000);
log.info("执行监控的功能 ...");
} catch (InterruptedException e) {
log.info("设置打断标记 ...");
thread.interrupt(); //重新设置打断标记，下次循环就能退出
e.printStackTrace();
}
}
}
}, "monitor");
monitor.start();
}
// 终止线程
public void stop() {
monitor.interrupt();
}
}
5 不推荐使用的方法
stop，suspend，resume
容易破坏同步代码块，造成线程死锁
6 守护线程
默认情况下，java进程需要等待所有的线程结束后才会停止，但是有一种特殊的线程，叫做守护线程，在其他线程全部结束的时候即使守护线程还未结束代码未执行完java进程也会停止。
普通线程t1可以调用 t1.setDeamon(true); 方法变成守护线程。
垃圾回收器就是一种守护线程
线程状态
线程的5种状态
初始状态，仅仅是在语言层面上创建了线程对象，即Thead thread = new Thead();，还未与操作系统线程关联
可运行状态，也称就绪状态，指该线程已经被创建，与操作系统相关联，等待cpu给它分配时间片就可运行
运行状态指线程获取了CPU时间片，正在运行
当CPU时间片用完，线程会转换至【可运行状态】，等待 CPU再次分配时间片，会导致我们前面讲到的上下文切换
阻塞状态
如果调用了阻塞API，如BIO读写文件，那么线程实际上不会用到CPU，不会分配CPU时间片，会导致上下文切换，进入【阻塞状态】
等待BIO操作完毕，会由操作系统唤醒阻塞的线程，转换至【可运行状态】
与【可运行状态】的区别是，只要操作系统一直不唤醒线程，调度器就一直不会考虑调度它们，CPU就一直不会分配时间片
终止状态表示线程已经执行完毕，生命周期已经结束，不会再转换为其它状态
线程的6种状态
NEW 跟五种状态里的初始状态是一个意思
RUNNABLE 是当调用了 start() 方法之后的状态，注意，Java API 层面的 RUNNABLE 状态涵盖了操作系统层面的【可运行状态】、【运行状态】和【io阻塞状态】（由于 BIO 导致的线程阻塞，在 Java 里无法区分，仍然认为是可运行）
BLOCKED ， WAITING ， TIMED_WAITING 都是 Java API 层面对【阻塞状态】的细分。
/**
* 演示 java 线程的 6 种状态(NEW, RUNNABLE, TERMINATED, BLOCKED, WAITING, TIMED_WAITING)
*/
@Slf4j(topic = "c.Code_15_Test")
public class Code_15_Test {
public static void main(String[] args) {
// NEW
Thread t1 = new Thread(() -> {
log.info("NEW 状态");
}, "t1");
// RUNNABLE
Thread t2 = new Thread(() -> {
while (true) {
}
}, "t2");
t2.start();
// TERMINATED
Thread t3 = new Thread(() -> {
log.info("running");
}, "t3");
t3.start();
// TIMED_WAITING
Thread t4 = new Thread(() -> {
synchronized (Code_15_Test.class) {
try {
Thread.sleep(100000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}, "t4");
t4.start();
// WAITING
Thread t5 = new Thread(() -> {
try {
t2.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}, "t5");
t5.start();
Thread t6 = new Thread(() -> {
synchronized (Code_15_Test.class) {
try {
Thread.sleep(100000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}, "t6");
t6.start();
// 主线程休眠 1 秒, 目的是为了等待 t3 线程执行完
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
log.info("t1 线程状态: {}", t1.getState());
log.info("t2 线程状态: {}", t2.getState());
log.info("t3 线程状态: {}", t3.getState());
log.info("t4 线程状态: {}", t4.getState());
log.info("t5 线程状态: {}", t5.getState());
log.info("t6 线程状态: {}", t6.getState());
}
}
8 sleep，yield，wait，join 对比
https://www.cnblogs.com/aspirant/p/8876670.html
三．并发之共享模型
线程共享数据因为分时系统带来的问题
线程出现问题的根本原因是线程A对共享变量的操作还没写入主存，刚好时间片用完了，CPU把时间片分配给另一个线程B使用，而因为线程的上下文切换功能，线程A的程序计数器会记住还没写入的操作指令，在线程B对变量的操作之后，线程A又把操作写入，这样就让线程B的操作白费，这就是问题
例举： 两个线程分别执行i++ i-- 各5000次，结果输出i的值是不确定的
i++ i–的底层指令操作流程（既有读也有写）
在JVM学习中学过，两个线程互相对一个共享变量执行加减，结果是不确定的，就是因为CPU的分时系统，时间片交替分配线程，根本原因是线程执行了读写操作，上下文切换，直接问题是出现了指令交错
阻塞式的解决方案 synchronized Lock
1 synchronized 语法
synchronized(对象) {
临界区
}
2 synchronized解决
阻塞加锁，维护了原子性（不可分割），i++和i–的四条指令会一起执行完才让出CPU，在线程的时间片用完后，因为synchronized还锁着，因此CPU会继续把时间片给线程，保证了指令完整的运行，不会出现指令交错的情况
阻塞加锁也会出现上下文切换，因为当时间片用完后，其他线程会尝试获取锁，在尝试获取的前后，我们需要对指令的位置进行记录，下次调用才能继续之前的指令位置运行下去
**注意：**synchronized需要锁住同一个对象，而且需要共享变量的线程每一个都加入锁，缺一不可
3 synchronized 加在方法上
加在成员方法上，锁住的是this对象，而不是锁方法
public class Test {
// 在方法上加上synchronized关键字
public synchronized void test() {
}
// 等价于
public void test() {
synchronized(this) { // 锁住的是对象
}
}
}
加在静态方法上，锁住的是类
public class Test {
// 在静态方法上加上 synchronized 关键字
public synchronized static void test() {
}
//等价于
public void test() {
synchronized(Test.class) { // 锁住的是类
}
}
}
小总结：
不加synchronized的方法不能保证原子性，可能执行一半就去执行其他的线程了
Synchronized锁非静态方法，则锁的是实例化的对象
Synchronized锁静态方法，则锁的是类Class
Sleep不会释放锁，会释放cpu的使用权
锁住同一个对象的两个线程才能实现线程阻塞同步的效果
三个典例：
变量的线程安全分析
1）成员变量和静态变量的线程安全分析
如果变量没有在线程间共享，那么线程对该变量操作是安全的
如果变量在线程间共享
如果只有读操作，则线程安全
如果有读写操作，则这段代码就是临界区，需要考虑线程安全问题
2）局部变量线程安全分析
局部变量【局部变量被初始化为基本数据类型】是安全的
局部变量是引用类型或者是对象引用则未必是安全的
如果局部变量引用的对象没有引用线程共享的对象，那么是线程安全的
如果局部变量引用的对象引用了一个线程共享的对象，那么要考虑线程安全问题
3）线程安全的情况
局部变量被初始化为基本数据类型是安全的，代码如下，因为每个线程都会有一份 test() 放在线程私有的栈中，多个线程就有多个，是不被多个线程共享的，所有就没有线程安全问题。
4）线程不安全的情况
如果局部变量引用的对象逃离方法的范围，那么要考虑线程安全的，分析如下代码：
@Slf4j(topic = "c.Code_18_Test")
public class Code_18_Test {
public static void main(String[] args) {
UnsafeTest unsafeTest = new UnsafeTest();
for(int i = 0; i < 10; i++) {
new Thread(() -> {
unsafeTest.method1();
}, "t" + i).start();
}
}
}
class UnsafeTest {
List<Integer> list = new ArrayList<>();
public void method1() {
for (int i = 0; i < 200; i++) {
method2();
method3();
}
}
public void method2() {
list.add(1);
}
public void method3() {
list.remove(0);
}
}
5）不安全原因分析
两个线程对同一个list操作，则会出现CPU分时，上下文切换导致指令交错
6）解决方法
将 list 修改成局部变量，然后将 list 作为引用传入方法中，因为局部变量是每个线程私有的，不会出现共享问题
class SafeTest {
public void method1() {
List<Integer> list = new ArrayList<>();
for (int i = 0; i < 200; i++) {
method2(list);
method3(list);
}
}
public void method2(List<Integer> list) {
list.add(1);
}
public void method3(List<Integer> list) {
list.remove(0);
}
}
7）常见线程安全类
String
Integer
StringBuffer
Random
Vector （List的线程安全实现类）
Hashtable （Hash的线程安全实现类）
java.util.concurrent 包下的类
上面的jdk给我们封装的线程安全容器的含义是 多个线程调用它们同一个实例的某个方法时，是线程安全的，因为每一个方法内部是原子性的，但是 如果在一个线程内执行多个方法，那不能保证这个方法组合是原子性
不可变类的线程安全：
String和integer都是不可变的，如果数据没有修改操作，则线程是安全的。那String的replace和substring的修改操作内部不是对原数据的修改，而是创建了新的数据，这就实现了不可变类的功能，实现了线程安全
8）举例-
方法直接的调用
public class MyServlet extends HttpServlet {
// 是否安全
private UserService userService = new UserServiceImpl();
public void doGet(HttpServletRequest request, HttpServletResponse response) {
userService.update(...);
}
}
public class UserServiceImpl implements UserService {
// 是否安全
private UserDao userDao = new UserDaoImpl();
public void update() {
userDao.update();
}
}
public class UserDaoImpl implements UserDao {
public void update() {
String sql = "update user set password = ? where username = ?";
// 是否安全
try (Connection conn = DriverManager.getConnection("","","")){
// ...
} catch (Exception e) {
// ...
}
}
}
安全，UserDaoImpl类内没有成员变量，是线程安全的，所以userservice也是线程安全的，虽然他有一个成员变量，但是是private线程私有的，在每个栈内都有，同理MyServlet也是线程安全的
如果dao层的connection又方法内的变量变成类内的成员变量，则会被多个service共享，则会出现线程不安全
但是如果在上面的基础上，对service层进行修改，在方法内常见userDao实例，则是线程安全的，因为这时候每个线程栈都有自己的userDao，则等于connection变量不会被多个线程共享，但是不推荐这样编写代码
其中 foo 的行为是不确定的，可能导致不安全的发生，被称之为外星方法，因为 foo 方法可以被重写，导致线程不安全。在 String 类中就考虑到了这一点，String 类是 final 关键字声明的，子类不能重写它的方法。
转账线程的分析
对于转账的线程，其方法内部的临界区其实是需要有两个共享变量的，a的账户的余额和b的账户的余额，因此在加锁的时候，我们不能直接在方法上加synchronized，因为这时只是锁住了自己的账户，而没有锁住转账的目标账户的共享变量余额，正确的加锁方式应该是 synchronized（account.class) 锁住account类，这样实例化对象的a和b就都锁住了，但是不建议这样锁，因为这样会导致线程只能两个两个账户同步进行转账，效率非常的慢。
四．Monitor锁概念
1）Java 对象头
以 32 位虚拟机为例,普通对象的对象头结构如下，其中的 Klass Word 为指针，指向对应的 Class 对象；
普通对象
Klass就是指针指向堆中的class的类对象，堆中也有指针指向方法区中的class可以获取到类结构信息
（贴出JVM的一张模型概念图）
数组对象
其中 Mark Word 结构为
Integer比普通的int多占8个对象头的数据大小，还要存取int的4个字节
图解流程：
1刚开始时 Monitor 中的 Owner 为 null
2当 Thread-2 执行 synchronized(obj){} 代码时就会将 Monitor 的所有者Owner 设置为 Thread-2，上锁成功，Monitor 中同一时刻只能有一个 Owner
3当 Thread-2 占据锁时，如果线程 Thread-3 ，Thread-4 也来执行synchronized(obj){} 代码，就会进入 EntryList（阻塞队列） 中变成BLOCKED（阻塞） 状态
4Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争时是非公平的
5图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程，后面讲 wait-notify 时会分析
如果不锁同一个对象，则不会进入同一个monitor，则上述效果无效
五．synchronized原理进阶
轻量级锁
轻量级锁的使用场景是：如果一个对象虽然有多个线程要对它进行加锁，但是加锁的时间是错开的（也就是没有人可以竞争的），那么可以使用轻量级锁来进行优化。
轻量级锁对使用者是透明的，即语法仍然是 synchronized ，假设有两个方法同步块，利用同一个对象加锁
static final Object obj = new Object();
public static void method1() {
synchronized( obj ) {
// 同步块 A
method2();
}
}
public static void method2() {
synchronized( obj ) {
// 同步块 B
}
}
每次指向到 synchronized 代码块时，都会创建锁记录（Lock Record）对象，每个线程都会包括一个锁记录的结构，锁记录内部可以储存对象的 Mark Word 和对象引用 reference
让锁记录中的 Object reference 指向对象，并且尝试用 cas(compare and sweep) 替换 Object 对象的 Mark Word ，将 Mark Word 的值存入锁记录中。
如果 cas 替换成功，那么对象的对象头储存的就是锁记录的地址和状态 00 表示轻量级锁，如下所示
如果cas失败，有两种情况
如果是其它线程已经持有了该 Object 的轻量级锁，那么表示有竞争，进入锁膨胀阶段。
如果是自己的线程已经执行了 synchronized 进行加锁，那么再添加一条 Lock Record 作为重入的计数，同一个栈内对同一个object对象加锁，这就是锁重入。
当线程退出 synchronized 代码块的时候，如果获取的是取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一
当线程退出 synchronized 代码块的时候，如果获取的锁记录取值不为 null，那么使用 cas 将 Mark Word 的值恢复给对象
成功则解锁成功
失败，则说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程（退出对象头的monitor中的owener，唤醒entrySet中的等待队列竞争此锁的使用权）
锁膨胀
如果在尝试加轻量级锁的过程中，cas 操作无法成功，这是有一种情况就是其它线程已经为这个对象加上了轻量级锁，这时线程会出现自旋的情况，当自选多次后还是得不到轻量级锁，这时就要进行锁膨胀，将轻量级锁变成重量级锁。
1 当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁
2这时 Thread-1 加轻量级锁失败，进入锁膨胀流程
即为对象申请Monitor锁，让Object指向重量级锁地址
然后自己进入Monitor 的EntryList 变成BLOCKED状态
3当 Thread-0 退出 synchronized 同步块时，使用 cas 将 Mark Word 的值恢复给对象头，对象的对象头指向 Monitor，那么会进入重量级锁的解锁过程，即按照 Monitor 的地址找到 Monitor 对象，将 Owner 设置为 null ，唤醒 EntryList 中的 Thread-1 线程
自旋优化
重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即在自旋的时候持锁的线程释放了锁），那么当前线程就可以不用进行上下文切换就获得了锁
1.自旋重试成功的情况
2.自旋重试失败的情况，自旋了一定次数还是没有等到持锁的线程释放锁
小结
适合多核CPU，因为自旋会占用CPU，一直在运行
在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
Java 7 之后不能控制是否开启自旋功能
偏向锁
锁重入的时候，虽然知道锁是自己家的，但是每次它还是会去CAS操作，尝试把对象头改成新的锁记录的地址，这个操作也是会影响性能的。这时就需要偏向锁
1 偏向锁执行优化操作
只有第一次使用 CAS 时将对象的 Mark Word 头设置为偏向线程 ID，之后这个入锁线程再进行重入锁时，发现线程 ID 是自己的，那么就不用再进行CAS了。
2 详细解析偏向锁
Mark word内容 主要是锁的mark word的倒数三位是101
验证结论
使用jar包有点问题，测试结果没调试出来
小结：
对象创建时，默认是开启了偏向锁，因此他的markword的值的后三位应该是101，但是会有延迟，需要加载一会才会由001变成101
Markword里面如果设置了线程号，则在解锁后，线程号还会继续保存，直到被其他线程使用才会发生改变
对于单线程里面多个方法同时加锁，我们才需要使用偏向锁提高效率，但对于多线程经常互相调用，则不适合，则需要禁用默认偏向锁，而使用轻量级锁来提高效率
撤销偏向**
以下几种情况会使对象的偏向锁失效
调用对象的 hashCode 方法
多个线程使用该对象
调用了 wait/notify 方法（调用wait方法会导致锁膨胀而使用重量级锁）
当有其他线程使用偏向锁对象时，会将默认的偏向锁101升级为轻量级锁00（前提是多线程的调用是错开的），轻量级锁也可以再变成偏向锁，如果出现线程争抢，锁膨胀，则会进一步升级为重量级锁10，重量级锁不能降级
批量重偏向
如果对象虽然被多个线程访问，但是线程间不存在竞争，这时偏向 t1 的对象仍有机会重新偏向 t2
重偏向会重置Thread ID
当撤销超过20次后（超过阈值），JVM 会觉得是不是偏向错了，这时会在给对象加锁时，重新偏向至加锁线程。
这个是JVM内部的优化机制
大致理解就是，原来几十个线程都创建锁对象偏向t1，这时我们不操作t1了，我们一直对t2线程锁住这些偏向锁的对象，那在执行20次之后，jvm内部就会把剩下的偏向t1的对象锁全部修改mark word的线程号ID为t2的，这就是批量重偏向
批量撤销
当撤销偏向锁的阈值超过== 40== 以后，给JVM的默认机制整不自信了，觉得自己不应该设置默认偏向锁，所以就会利用JVM内部的JIT即时编译器将整个类的对象都改为不可偏向的，也就是都变成001，而不是101
锁消除：
如果锁没有什么用的话，JIT即时编译器就会消除锁，提高运行速率
六．Wait
Wait/Notify 原理*
**为什么需要wait：**由于条件不允许，线程一直占着锁，其他人就得一直阻塞，而加入wait，这时锁释放了，这样就可以让其他线程先进来执行，而自己在另一个休息室里面继续处理，直到解决了，调用notify方法，离开休息室，继续加入竞争锁的队列
图
原理：
锁对象调用wait方法（obj.wait），就会使当前线程进入 WaitSet 中，变为 WAITING 状态。
处于BLOCKED和 WAITING 状态的线程都为阻塞状态，CPU 都不会分给他们时间片。但是有所区别：
BLOCKED 状态的线程是在竞争对象时，发现 Monitor 的 Owner 已经是别的线程了，此时就会进入 EntryList 中，并处于 BLOCKED 状态
WAITING 状态的线程是获得了对象的锁，但是自身因为某些原因需要进入阻塞状态时，锁对象调用了 wait 方法而进入了 WaitSet 中，处于 WAITING 状态
BLOCKED 状态的线程会在锁被释放的时候被唤醒，但是处于 WAITING 状态的线程只有被锁对象调用了 notify 方法(obj.notify/obj.notifyAll)，才会被唤醒。
API介绍：
obj.wait() 让进入object监视器的线程到waitSet等待，释放锁
obj.wait( long n ) 进入waitSet，设置等待时间，释放锁
Obj.notify() 在object上正在waitSet等待的线程中随机挑选一个唤醒
Obj.notifyAll() 让object上正在waitSet等待的线程全部唤醒
小总结
它们都是对象的调用，调用的前提是必须获得此对象的锁，在jvm模型的意思就是monitor里面有owener，waitSet，entrtSet，线程首先得需要进入到monitor里面成为owener占有这个对象，然后才能调用wait进入waitSet休息室，同时释放锁，让entrtSet的竞争队列进入owener成为新主人
如果在不是锁的拥有者的前提下调用wait方法，会报错，必须在synchronized内
在调用wait的时候，默认把偏向锁升级重量锁，因为重量锁才有monitor监视器
Wait与sleep的区别
Sleep 是 Thread 类的静态方法，Wait 是 Object 的方法，Object 又是所有类的父类，所以所有类都有Wait方法。
Sleep 在阻塞的时候不会释放锁，而 Wait 在阻塞的时候会释放锁，它们都会释放 CPU 资源。
Sleep 不需要与 synchronized 一起使用，而 Wait 需要与 synchronized 一起使用（对象被锁以后才能使用）
使用 wait 一般需要搭配 notify 或者 notifyAll 来使用，不然会让线程一直等待。
共同点： 状态都是timed_waiting
Wait使用场景
什么时候适合使用wait：
当线程不满足某些条件，需要暂停运行时，可以使用 wait 。这样会将对象的锁释放，让其他线程能够继续运行。如果此时使用 sleep，会导致所有线程都进入阻塞，导致所有线程都没法运行，直到当前线程 sleep 结束后，运行完毕，才能得到执行。
注意：当有多个线程在运行时，对象调用了 wait 方法，此时这些线程都会进入 WaitSet 中等待。如果这时使用了 notify 方法，可能会造成虚假唤醒（唤醒的不是满足条件的等待线程），这时就需要使用
notifyAll 方法
synchronized (lock) {
while(//不满足条件，一直等待，避免虚假唤醒) {
lock.wait();
}
//满足条件后再运行
}
synchronized (lock) {
//唤醒所有等待线程
lock.notifyAll
();
}
所以以后在wait方法的时候，要加while，这样就会避免虚假唤醒，原理是如果是if，那在没准备好条件的时候就唤醒了wait线程，if判断还是失败，那应该执行的代码就不会执行，线程会销毁，而我们是要等到条件满足然后执行，因此加入while，就可以被多次唤醒，但又多次wait，直到条件满足才执行然后销毁
同步模式之保护性暂停
即 Guarded Suspension，用在一个线程等待另一个线程的执行结果，要点：
有一个结果需要从一个线程传递到另一个线程，让他们关联同一个 GuardedObject
如果有结果不断从一个线程到另一个线程那么可以使用消息队列（见生产者/消费者）
JDK 中，join 的实现、Future 的实现，采用的就是此模式
因为要等待另一方的结果，因此归类到同步模式
/**
- 同步模式-保护性暂停 (Guarded-Suspension-pattern)
*/
@Slf4j(topic = "c.Code_23_Test")
public class Code_23_Test {
public static void main(String[] args) {
for (int i = 0; i < 3; i++) {
new People().start();
}
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
for(Integer id : Mailboxes.getIds()) {
new Postman(id, "内容 " + id).start();
}
}
}
@Slf4j(topic = "c.People")
class People extends Thread {
@Override
public void run() {
GuardedObject guardedObject = Mailboxes.createGuardedObject();
log.info("收信的为 id: {}", guardedObject.getId());
Object o = guardedObject.get(5000);
log.info("收到信的 id: {}, 内容: {}", guardedObject.getId(), o);
}
}
@Slf4j(topic = "c.Postman")
class Postman extends Thread {
private int id;
private String mail;
public Postman(int id, String mail) {
this.id = id;
this.mail = mail;
}
@Override
public void run() {
GuardedObject guardedObject = Mailboxes.getGuardedObject(id);
log.info("送信的 id: {}, 内容: {}", id, mail);
guardedObject.complete(mail);
}
}
class Mailboxes {
private static int id = 1;
private static Map<Integer, GuardedObject> boxes = new Hashtable<>();
public static synchronized int generateId() {
return id++;
}
// 用户会进行投信
public static GuardedObject createGuardedObject() {
GuardedObject guardedObject = new GuardedObject(generateId());
boxes.put(guardedObject.getId(), guardedObject);
return guardedObject;
}
// 派件员会派发信
public static GuardedObject getGuardedObject(int id) {
return boxes.remove(id);
}
public static Set<Integer> getIds() {
return boxes.keySet();
}
}
class GuardedObject {
private int id;
public GuardedObject(int id) {
this.id = id;
}
public int getId() {
return this.id;
}
private Object response;
// 优化等待时间
public Object get(long timeout) {
synchronized (this) {
long begin = System.currentTimeMillis();
long passTime = 0;
while (response == null) {
long waitTime = timeout - passTime; // 剩余等待时间
if(waitTime <= 0) {
break;
}
try {
this.wait(waitTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
passTime = System.currentTimeMillis() - begin;
}
return response;
}
}
public void complete(Object response) {
synchronized (this) {
this.response = response;
this.notify();
}
}
}
异步模式之生产者/消费者
要点
与前面的保护性暂停中的 GuardObject 不同，不需要产生结果和消费结果的线程一一对应
消费队列可以用来平衡生产和消费的线程资源
生产者仅负责产生结果数据，不关心数据该如何处理，而消费者专心处理结果数据
消息队列是有容量限制的，满时不会再加入数据，空时不会再消耗数据
JDK 中各种阻塞队列，采用的就是这种模式
“异步”的意思就是生产者产生消息之后消息没有被立刻消费，而“同步模式”中，消息在产生之后被立刻消费了。
这里的代码我没有按照视频去还原出来，大致关键的地方就是要创建两个线程，生产者和消费者一个消息队列类，里面创建了成员变量list作为存储消息的容器，然后创建了两个方法分别为put和take表示生产者和消费者调用
这两个方法的锁对象都是list，put的逻辑是 如果队列满了，则list.wait（），take方法会执行消费list.remove，然后list.notify（）唤醒put方法来生产
同理 take方法入口也是有判断的，如果list队列为空，则则list.wait（），put方法会执行对list.add加入消息，然后list.notify（）唤醒take方法来消费
Join原理
七．park & unpark
1）基本使用
park & unpark 是 LockSupport 线程通信工具类的静态方法。
// 暂停当前线程
LockSupport.park();
// 恢复某个线程的运行
LockSupport.unpark;
特点
与Object的wait & notify相比
Wait，notify和notifyAll 必须配合Object Monitor一起使用，而unpark不必
Park & unpark是以线程为单位阻塞和唤醒的，是精确的
Park & unpark可以先unpark，而wait & notify不能先notify
2）park unpark 原理
每个线程都有自己的一个 Parker 对象，由三部分组成 _counter，_cond 和_mutex
打个比喻线程就像一个旅人，Parker 就像他随身携带的背包，条件变量 _ cond 就好比背包中的帐篷。_counter 就好比背包中的备用干粮（0 为耗尽，1 为充足）
调用 park 就是要看需不需要停下来歇息
如果备用干粮耗尽，那么钻进帐篷歇息
如果备用干粮充足，那么不需停留，继续前进
调用 unpark，就好比令干粮充足
如果这时线程还在帐篷，就唤醒让他继续前进
如果这时线程还在运行，那么下次他调用 park 时，仅是消耗掉备用干粮，不需停留继续前进
因为背包空间有限，多次调用 unpark 仅会补充一份备用干粮
先调用park再调用upark的过程
先调用 park
1.当前线程调用 Unsafe.park() 方法
2.检查 _counter ，本情况为 0，这时，获得 _mutex 互斥锁(mutex对象有个等待队列 _cond)
3.线程进入 _cond 条件变量阻塞
4.设置 _counter = 0
2调用 unpark
1.调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
2.唤醒 _cond 条件变量中的 Thread_0
3.Thread_0 恢复运行
4.设置 _counter 为 0
先调用unpark再调用park的过程
1.调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
2.当前线程调用 Unsafe.park() 方法
3.检查 _counter ，本情况为 1，这时线程无需阻塞，继续运行
4.设置 _counter 为 0
八．线程状态转换*
情况一：NEW –> RUNNABLE
当调用了 t.start() 方法时，由 NEW –> RUNNABLE
情况二： RUNNABLE <–> WAITING
当调用了t 线程用 synchronized(obj) 获取了对象锁后，调用 obj.wait() 方法时，t 线程从 RUNNABLE –> WAITING
调用 obj.notify() ， obj.notifyAll() ， t.interrupt() 时，会唤醒t线程加入到entrySet竞争队列状态为BLOCKED，并竞争下一次的锁占有权，成功就变成RUNNABLE
竞争锁成功，t 线程从 WAITING –> BLOCKED -> RUNNABLE
竞争锁失败，t 线程从 WAITING –> BLOCKED
情况三：RUNNABLE <–> WAITING
当前线程调用 t.join() 方法时，当前线程从 RUNNABLE –> WAITING
注意是当前线程在 t 线程对象的监视器上等待
t 线程运行结束，或调用了当前线程的 interrupt() 时，当前线程从 WAITING –> RUNNABLE
情况四： RUNNABLE <–> WAITING
当前线程调用 LockSupport.park() 方法会让当前线程从 RUNNABLE –> WAITING
调用 LockSupport.unpark(目标线程) 或调用了线程 的 interrupt() ，会让目标线程从 WAITING –> RUNNABLE
情况五： RUNNABLE <–> TIMED_WAITING
t 线程用 synchronized(obj) 获取了对象锁后
调用 ==obj.wait(long n) ==方法时，t 线程从 RUNNABLE –> TIMED_WAITING
t 线程等待时间超过了 n 毫秒，或调用 obj.notify() ， obj.notifyAll() ， t.interrupt() 时
竞争锁成功，t 线程从 TIMED_WAITING –> RUNNABLE
竞争锁失败，t 线程从 TIMED_WAITING –> BLOCKED
情况六：RUNNABLE <–> TIMED_WAITING
当前线程调用 ==t.join(long n) ==方法时，当前线程从 RUNNABLE –> TIMED_WAITING
注意是当前线程在 t 线程对象的监视器上等待
当前线程等待时间超过了 n 毫秒，或 t 线程运行结束，或调用了当前线程的 interrupt() 时，当前线程从 TIMED_WAITING –> RUNNABLE
情况七：RUNNABLE <–> TIMED_WAITING
当前线程调用 Thread.sleep(long n) ，当前线程从 RUNNABLE –> TIMED_WAITING
当前线程等待时间超过了 n 毫秒，当前线程从 TIMED_WAITING –> RUNNABLE
情况八：RUNNABLE <–> TIMED_WAITING
当前线程调用 LockSupport.parkNanos(long nanos) 或 LockSupport.parkUntil(long millis) 时，当前线 程从 RUNNABLE –> TIMED_WAITING
调用 LockSupport.unpark(目标线程) 或调用了线程 的 interrupt() ，或是等待超时，会让目标线程从 TIMED_WAITING–> RUNNABLE
情况九：RUNNABLE <–> BLOCKED
t 线程用 synchronized(obj) 获取了对象锁时如果竞争失败，
从 RUNNABLE –> BLOCKED
持 obj 锁线程的同步代码块执行完毕，会唤醒该对象上所有 BLOCKED 的线程重新竞争，如果其中 t 线程竞争 成功，从 BLOCKED –> RUNNABLE ，其它失败的线程仍然 BLOCKED
情况十： RUNNABLE <–> TERMINATED
当前线程所有代码运行完毕，进入 TERMINATED
只要是阻塞的线程，都可以被interrupt打断重新加入竞争锁队列
九．活跃性
多把锁：
锁对象要注意可以的话把锁粒度调低，锁的对象能小尽量小，避免不必要的互斥情况，让并发度提高，但是锁对象的粒度变低，逻辑设置不当会容易造成死锁
线程因为某些原因，导致代码一直无法执行完毕，这种的现象叫做活跃性。
2）死锁
有这样的情况：一个线程需要同时获取多把锁，这时就容易发生死锁
如： t1 线程获得 A 对象锁，接下来想获取 B 对象的锁
t2 线程获得 B 对象锁，接下来想获取 A 对象的锁
public static void main(String[] args) {
final Object A = new Object();
final Object B = new Object();
new Thread(()->{
synchronized (A) {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (B) {
}
}
}).start();
new Thread(()->{
synchronized (B) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (A) {
}
}
}).start();
}
定位死锁的方法
加粗样式检测死锁可以使用 jconsole工具；或者使用 jps 定位进程 id，再用 jstack 根据进程 id 定位死锁。
哲学家就餐问题
有五位哲学家，围坐在圆桌旁。 他们只做两件事，思考和吃饭，思考一会吃口饭，吃完饭后接着思考。 吃饭时要用两根筷子吃，桌上共有 5 根筷子，每位哲学家左右手边各有一根筷子。 如果筷子被身边的人拿着，自己就得等待 。
当每个哲学家即线程持有一根筷子时，他们都在等待另一个线程释放锁，因此造成了死锁。这种线程没有按预期结束，执行不下去的情况
除了死锁以外，还有活锁和饥饿者两种情况。
避免死锁问题：
顺序加锁，不要交叉获取锁
3）活锁
活锁出现在两个线程互相改变对方的结束条件，谁也无法结束
比如一个线程一直加，一个线程一直减，然后都死循环在范围内，无法跳出
死锁与活锁的区别
死锁是因为线程互相持有对象想要的锁，并且都不释放，最后到时线程阻塞，停止运行的现象。
活锁是因为线程间修改了对方的结束条件，而导致代码一直在运行，却一直运行不完的现象。
避免活锁的方法
在线程执行时，中途给予不同的间隔时间即可。
4）饥饿
某些线程因为优先级太低，导致一直无法获得资源的现象。
在使用顺序加锁时，可能会出现饥饿现象
十．ReentrantLock
和 synchronized 相比具有的的特点
可中断
可以设置超时时间
可以设置为公平锁 (先到先得)== 避免饥饿==
支持多个条件变量( 具有多个 WaitSet)
// 获取ReentrantLock对象
private ReentrantLock lock = new ReentrantLock();
// 加锁
lock.lock();
try {
// 需要执行的代码 临界区
}finally {
// 释放锁
lock.unlock();
}
1）可重入
可重入是指同一个线程如果首次获得了这把锁，那么因为它是这把锁的拥有者，因此有权利再次获取这把锁
如果是不可重入锁，那么第二次获得锁时，自己也会被锁挡住
2）可打断
如果某个线程处于阻塞状态，可以调用其 interrupt 方法让其停止阻塞，获得锁失败
简而言之就是：处于阻塞状态的线程，被打断了就不用阻塞了，直接停止运行
3）锁超时
使用 lock.tryLock 方法会返回获取锁是否成功。如果成功则返回 true ，反之则返回 false 。
并且 tryLock 方法可以指定等待时间，参数为：tryLock(long timeout, TimeUnit unit), 其中 timeout 为最长等待时间，TimeUnit 为时间单位
简而言之就是：获取锁失败了、获取超时了或者被打断了，不再阻塞，直接停止运行。
不设置等待时间
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock();
Thread t1 = new Thread(() -> {
// 未设置等待时间，一旦获取失败，直接返回false
if(!lock.tryLock()) {
System.out.println("获取失败");
// 获取失败，不再向下执行，返回
return;
}
System.out.println("得到了锁");
lock.unlock();
});
lock.lock();
try{
t1.start();
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
设置等待时间
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock();
Thread t1 = new Thread(() -> {
try {
// 判断获取锁是否成功，最多等待1秒
if(!lock.tryLock(1, TimeUnit.SECONDS)) {
System.out.println("获取失败");
// 获取失败，不再向下执行，直接返回
return;
}
} catch (InterruptedException e) {
e.printStackTrace();
// 被打断，不再向下执行，直接返回
return;
}
System.out.println("得到了锁");
// 释放锁
lock.unlock();
});
lock.lock();
try{
t1.start();
// 打断等待
t1.interrupt();
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
**解决哲学家就餐问题：**不使用顺序加锁syn，而是使用trylock，就不会跟syn一样获取不到锁就一直阻塞不动，trylock判断锁获取失败，也能跳出阻塞状态结束进程
4）公平锁
在线程获取锁失败，进入阻塞队列时，先进入的会在锁被释放后先获得锁。这样的获取方式就是公平的。
// 默认是不公平锁，需要在创建时指定为公平锁
ReentrantLock lock = new ReentrantLock(true);
虽然可以解决饥饿问题，但是一般不设置，会降低并发度
5）条件变量
synchronized 中也有条件变量，就是我们讲原理时那个 waitSet 休息室，当条件不满足时进入waitSet 等待。
ReentrantLock 的条件变量比 synchronized 强大之处在于，它是支持多个条件变量的
synchronized 是那些不满足条件的线程都在一间休息室等消息
而 ReentrantLock 支持多间休息室，有专门等烟的休息室、专门等早餐的休息室、唤醒时也是按休息室来唤醒 *.sign（） *.sighnAll（）
使用要点：
await 前需要获得锁 *.lock（）
await 执行后，会释放锁，进入 conditionObject 等待
await 的线程被唤醒（或打断、或超时）取重新竞争 lock 锁
竞争 lock 锁成功后，从 await 后继续执行
十一．同步模式之顺序控制
线程 1 输出 a 5 次，线程 2 输出 b 5 次，线程 3 输出 c 5 次。现在要求输出 abcabcabcabcabc 怎么实现
1 Wait/notify实现：
因为有三个线程，所以我们wait上面的while判断语句不能使用boolean，因为boolean只有TF两种状态，需要使用一个int变量表示当前满足能执行的线程
@Slf4j(topic="c.Test")
public class Test6 {
public static void main(String[] args) {
WaitMan waitMan = new WaitMan(1,5);
new Thread(()->{
waitMan.run("a",1,2);
}).start();
new Thread(()->{
waitMan.run("b",2,3);
}).start();
new Thread(()->{
waitMan.run("c",3,1);
}).start();
}
}
class WaitMan{
int flag;
int loopNumber;
public WaitMan(int flag,int loopNumber){
this.flag = flag;
this.loopNumber = loopNumber;
}
public void run(String str,int flag,int next) {
for(int i=0;i<loopNumber;i++) {
synchronized (this) {
while (flag != this.flag) {
try {
this.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.print(str);
this.flag = next;
// 唤醒所有线程
this.notifyAll();
}
}
}
}
2）await/signal 实现
public class Code_34_Test {
public static void main(String[] args) {
AwaitAndSignal lock = new AwaitAndSignal(5);
Condition a = lock.newCondition();
Condition b = lock.newCondition();
Condition c = lock.newCondition();
new Thread(() -> {
lock.run("a", a, b);
}).start();
new Thread(() -> {
lock.run("b", b, c);
}).start();
new Thread(() -> {
lock.run("c", c, a);
}).start();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
lock.lock();
try {
a.signal();
}finally {
lock.unlock();
}
}
}
class AwaitAndSignal extends ReentrantLock {
public void run(String str, Condition current, Condition nextCondition) {
for(int i = 0; i < loopNumber; i++) {
lock();
try {
current.await();
System.out.print(str);
nextCondition.signal();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
unlock();
}
}
}
private int loopNumber;
public AwaitAndSignal(int loopNumber) {
this.loopNumber = loopNumber;
}
}
3）park/unpark 实现
public class Code_33_Test {
public static Thread t1, t2, t3;
public static void main(String[] args) {
ParkAndUnPark obj = new ParkAndUnPark(5);
t1 = new Thread(() -> {
obj.run("a", t2);
});
t2 = new Thread(() -> {
obj.run("b", t3);
});
t3 = new Thread(() -> {
obj.run("c", t1);
});
t1.start();
t2.start();
t3.start();
LockSupport.unpark(t1);
}
}
class ParkAndUnPark {
public void run(String str, Thread nextThread) {
for(int i = 0; i < loopNumber; i++) {
LockSupport.park();
System.out.print(str);
LockSupport.unpark(nextThread);
}
}
private int loopNumber;
public ParkAndUnPark(int loopNumber) {
this.loopNumber = loopNumber;
}
}
结论：
临界区：对共享变量的读写操作
使用 synchronized 互斥解决临界区的线程安全问题
掌握 synchronized 锁对象语法
掌握 synchronzied 加载成员方法和静态方法语法
掌握 wait/notify 同步方法
使用 lock 互斥解决临界区的线程安全问题
掌握 lock 的使用细节：可打断、锁超时、公平锁、条件变量
学会分析变量的线程安全性、掌握常见线程安全类的使用
了解线程活跃性问题：死锁、活锁、饥饿
（活锁以外，reentrelock都可以解决，解决方式就是加入超时时间）
应用方面
互斥：使用 synchronized 或 Lock 达到共享资源互斥效果，实现原子性效果，保证线程安全。
同步：使用 wait/notify 或 Lock 的条件变量来达到线程间通信效果。
原理方面
monitor、synchronized 、wait/notify 原理
synchronized 进阶原理
park & unpark 原理
模式方面
同步模式之保护性暂停
异步模式之生产者消费者
同步模式之顺序控制
88
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
