文章详细对比了悲观锁的代表synchronized和Lock与乐观锁的代表AtomicInteger，解释了两者的核心思想和性能影响。接着讨论了死锁的四大条件和预防策略，并通过代码示例展示了死锁的情况。此外，还介绍了volatile关键字的作用和解决的问题，以及ThreadLocal的原理和内存释放时机，强调了ThreadLocalMap中弱引用key的设计原因。
1、悲观锁 vs 乐观锁
要求
-
掌握悲观锁和乐观锁的区别
对比悲观锁synchronized 和 Lock 锁(important)与乐观锁AtomicInteger
-
1.1 悲观锁的代表是 synchronized 和 Lock 锁
-
其核心思想是【线程只有占有了锁，才能去操作共享变量，每次只有一个线程占锁成功，获取锁失败的线程，都得停下来等待】
-
线程从运行到阻塞、再从阻塞到唤醒，涉及线程上下文切换，如果频繁发生，影响性能
-
实际上，线程在获取 synchronized 和 Lock 锁时，如果锁已被占用，都会做几次重试操作，减少阻塞的机会
package Lock; import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; /* * 定义一个Runnable * 在Runnable定义同步代码块 * 先开启一个线程来执行同步代码块，不保证*/ public class Lock_Test { private static Lock lock= new ReentrantLock(); public static void main(String[] args) throws InterruptedException { Runnable runnable = ()->{ Boolean flag = false; try{ flag = lock.tryLock(3, TimeUnit.SECONDS); if (flag){ String name = Thread.currentThread().getName(); System.out.println(name+"加锁成功了"); Thread.sleep(360000); }else{ System.out.println("其他线程没有获取到锁，。。。。"); } } catch (Exception e) { e.printStackTrace(); } // finally { // if (lock!=null){ // lock.unlock(); // } // } }; Thread threadA = new Thread(runnable,"A"); threadA.start(); Thread.sleep(100); Thread threadB = new Thread(runnable, "B"); threadB.start(); } }1.2 乐观锁的代表是 AtomicInteger，使用 cas 来保证原子性
-
其核心思想是【无需加锁，每次只有一个线程能成功修改共享变量，其它失败的线程不需要停止，不断重试直至成功】
-
由于线程一直运行，不需要阻塞，因此不涉及线程上下文切换
-
它需要多核 cpu 支持，且线程数不应超过 cpu 核数
-
2、死锁（important）
关于死锁的一些结论：
参与死锁的进程数至少为两个；
参与死锁的所有进程均等待资源；
参与死锁的进程至少有两个已经占有资源；
死锁会浪费大量系统资源，甚至导致系统崩溃
实现代码：
package synchronized_demo;
public class DeadThreadDemo {
private static Object a = new Object();
private static Object b = new Object();
public static void main(String[] args) throws InterruptedException {
Thread thread = new Thread(()->{
synchronized(a){
String name = Thread.currentThread().getName();
System.out.println(name+"获得锁a");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(name+"试图去获取锁B");
synchronized(b){
System.out.println(name+"获取锁b");
}
}
},"线程a");
thread.start();
Thread.sleep(10);
Thread threadB = new Thread(()->{
synchronized(b){
String name = Thread.currentThread().getName();
System.out.println(name+"获得锁b");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(name+"试图去获取锁a");
synchronized(a){
System.out.println(name+"获取锁a");
}
}
},"线程b");
threadB.start();
}
}
线程a获得锁a
线程b获得锁b
线程b试图去获取锁a
线程a试图去获取锁B
死锁2.1 死锁的四大条件
1、 互斥条件：
进程要求对所分配的资源（如打印机）进行排他性控制，即在一段时间内某资源仅为一个进程所占有。此时若有其他进程请求该资源，则请求进程只能等待。
2、不可剥夺条件:
进程所获得的资源在未使用完毕之前，不能被其他进程强行夺走，即只能由获得该资源的进程自己来释放（只能是主动释放)。
3、 请求与保持条件：
进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放。
4、循环等待条件:
存在一种进程资源的循环等待链，链中每一个进程已获得的资源同时被 链中下一个进程所请求。即存在一个处于等待状态的进程集合{Pl, P2, …, pn}，其中Pi等 待的资源被P(i+1)占有（i=0, 1, …, n-1)，Pn等待的资源被P0占有
以上这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
2.1.1验证是否死锁：
2.2 预防死锁
破坏“互斥”条件:
就是在系统里取消互斥。若资源不被一个进程独占使用，那么死锁是肯定不会发生的。但一般来说在所列的四个条件中，“互斥”条件是无法破坏的。
破坏“占有并等待”条件:
破坏“占有并等待”条件，就是在系统中不允许进程在已获得某种资源的情况下，申请其他资源。即要想出一个办法，阻止进程在持有资源的同时申请其他资源。
方法一：一次申请所需的全部资源，即 “ 一次性分配”。
方法二：要求每个进程提出新的资源申请前，释放它所占有的资源。即“先释放后申请”。
破坏“不可抢占”条件：
破坏“不可抢占”条件就是允许对资源实行抢夺。
方法一：占有某些资源的同时再请求被拒绝，则该进程必须释放已占有的资源，如果有必要，可再次请求这些资源和另外的资源。
方法二：设置进程优先级，优先级高的可以抢占资源。
破坏“循环等待”条件：
将系统中的所有资源统一编号，所有进程必须按照资源编号顺序提出申请。
2.3 避免死锁
加锁顺序：线程按照一定的顺序加锁。
加锁时限：线程尝试获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁。
死锁检测：每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。
3、volatile（了解）
要求
-
掌握线程安全要考虑的三个问题
-
掌握 volatile 能解决哪些问题
原子性
-
起因：多线程下，不同线程的指令发生了交错导致的共享变量的读写混乱
-
解决：用悲观锁或乐观锁解决，volatile 并不能解决原子性
可见性
-
起因：由于编译器优化、或缓存优化、或 CPU 指令重排序优化导致的对共享变量所做的修改另外的线程看不到
-
解决：用 volatile 修饰共享变量，能够防止编译器等优化发生，让一个线程对共享变量的修改对另一个线程可见
有序性
-
起因：由于编译器优化、或缓存优化、或 CPU 指令重排序优化导致指令的实际执行顺序与编写顺序不一致
-
解决：用 volatile 修饰共享变量会在读、写共享变量时加入不同的屏障，阻止其他读写操作越过屏障，从而达到阻止重排序的效果
-
注意： volatile 写操作放在后面
读操作放在前面
-
volatile 变量写加的屏障是阻止上方其它写操作越过屏障排到 volatile 变量写之下
-
volatile 变量读加的屏障是阻止下方其它读操作越过屏障排到 volatile 变量读之上
-
volatile 读写加入的屏障只能防止同一线程内的指令重排
-
4、ThreadLocal （max）
要求
-
掌握 ThreadLocal 的作用与原理
-
掌握 ThreadLocal 的内存释放时机
作用
-
ThreadLocal 可以实现【资源对象】的线程隔离，让每个线程各用各的【资源对象】，避免争用引发的线程安全问题
-
ThreadLocal 同时实现了线程内的资源共享
原理
每个线程内有一个 ThreadLocalMap 类型的成员变量，用来存储资源对象
-
调用 set 方法，就是以 ThreadLocal 自己作为 key，资源对象作为 value，放入当前线程的 ThreadLocalMap 集合中
-
调用 get 方法，就是以 ThreadLocal 自己作为 key，到当前线程中查找关联的资源值
-
调用 remove 方法，就是以 ThreadLocal 自己作为 key，移除当前线程关联的资源值
ThreadLocalMap 的一些特点
-
key 的 hash 值统一分配
-
初始容量 16，扩容因子 2/3，扩容容量翻倍
-
key 索引冲突后用开放寻址法解决冲突
弱引用 key
ThreadLocalMap 中的 key 被设计为弱引用，原因如下
-
Thread 可能需要长时间运行（如线程池中的线程），如果 key 不再使用，需要在内存不足（GC）时释放其占用的内存
内存释放时机
-
被动 GC 释放 key
-
仅是让 key 的内存释放，关联 value 的内存并不会释放
-
-
懒惰被动释放 value
-
get key 时，发现是 null key，则释放其 value 内存
-
set key 时，会使用启发式扫描，清除临近的 null key 的 value 内存，启发次数与元素个数，是否发现 null key 有关
-
-
主动 remove 释放 key，value
-
会同时释放 key，value 的内存，也会清除临近的 null key 的 value 内存
-
推荐使用它，因为一般使用 ThreadLocal 时都把它作为静态变量（即强引用），因此无法被动依靠 GC 回收
-
5、总结
- 悲观锁的代表是 synchronized 和 Lock 锁
- 乐观锁的代表是 AtomicInteger
- 死锁的四大条件
- 互斥条件
- 不可剥夺条件
- 请求与保持条件
- 循环等待条件
-
ThreadLocal<T>其实是与线程绑定的一个变量。ThreadLocal和Synchonized都用于解决多线程并发访问。但是ThreadLocal与synchronized有本质的区别：
1、Synchronized用于线程间的数据共享，而ThreadLocal则用于线程间的数据隔离。
2、Synchronized是利用锁的机制，使变量或代码块在某一时该只能被一个线程访问。而ThreadLocal为每一个线程都提供了变量的副本，使得每个线程在某一时间访问到的并不是同一个对象，这样就隔离了多个线程对数据的数据共享。而Synchronized却正好相反，它用于在多个线程间通信时能够获得数据共享。
ThreadLocalMap使用ThreadLocal的弱引用作为key，当ThreadLocal变量被手动设置为null，即一个ThreadLocal没有外部强引用来引用它，当系统GC时，ThreadLocal一定会被回收。这样的话，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话(比如线程池的核心线程)，这些key为null的Entry的value就会一直存在一条强引用链：Thread变量 -> Thread对象 -> ThreaLocalMap -> Entry -> value -> Object 永远无法回收，造成内存泄漏。
6、建议采纳
如有建议或者错误请私信我进行修改，感谢！！！
扫一扫
964
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
