尚硅谷JUC并发编程
2024-10-29 11:14:10 0 举报AI智能生成
个人根据B站尚硅谷JUC课程学习并整理的
作者其他创作
大纲/内容
内容简介
面试题
子主题
1、一个线程不应该由其他线程来强制中断或停止，而是font color=\"#e74f4c\
2、在java中没有办法立即停止一条线程，然而停止线程却显得尤为重要，如取消一个耗时操作。因此，java提供了一种用于停止线程的协商机制——中断，也即中断标识协商机制
中断只是一种协商机制，Java没有给中断增加任何语法，中断的过程完全需要程序员自己实现。若要中断一个线程，你需要手动调用该线程的interrupt方法，该方法也仅仅是线程对象的中断标识设成true；接着你需要自己写代码不断地检测当前线程的标识位，如果为true，表示别的线程请求这条线程中断，此时究竟该做什么需要你自己写代码实现。
每个线程对象中都有一个中断标识位，用于表示线程是否被中断；该标识位为true表示中断，为false表示未中断；通过调用线程对象的interrupt方法将该线程的标识位设为true；可以在别的线程中调用，也可以在自己的线程中调用。
什么是中断机制
interrupt（）
interrupted（）
isInterrupted（）
API方法
中断的相关API方法之三大方法说明
通过一个volatile变量实现
通过AtomicBoolean
在需要中断的线程中不断监听中断状态，一旦发生中断，就执行相应的中断处理业务逻辑stop线程
API
通过Thread类自己带的中断api实例方法实现
如何中断运行中的线程
sleep方法抛出InterruptedException后，中断标识也被清空置为法拉瑟，我们在catch没有通过调用th.interrupt（）方法再次将中断标识置为true，这就导致无限循环了。
中断只是一种协商机制，修改中断标识位仅此而已，不是立刻stop打断
当前线程中断标识是true，是不是线程就立刻停止
静态方法，Thread.interrupted();判断线程是否被中断并清除当前中断状态。T这个方法做了两件事:1 返回当前线程的中断状态，测试当前线程是否已被中断2 将当前线程的中断状态清零并重新设为false，清除线程的中断状态此方法有点不好理解，如果连续两次调用此方法，则第二次调用将返回false，因为连续调用两次的结果可能不一样
说明
code
静态方法Thread.interrupted()
实际都是调用了同一个方法，只是传参不同，
isInterrupted()不会清除中断状态
interrupted()会清除中断状态
状态
isInterrupted()是实例方法
interrupted()是静态方法
方法
都会返回中断状态，两者比对
大厂面试题中断机制考点
总结
线程中断机制
是什么？
除非许可证可用，否则禁用当前线程以进行线程调度
park
如果给定线程尚不可用，则为其提供许可
unpark
LockSupport是什么
方式1：使用Object中的wait()方法让线程等待，使用Object中的notify()方法唤醒线程
方式2：使用JUC包中的Condition的await（）方法让线程等待，使用signal（）方法唤醒线程
方式3：LockSupport类可以阻塞当前线程以及唤醒指定背阻塞的线程
三种让线程等待和唤醒的方法
正常
wait方法和notify方法，两个都去掉同步代码块
异常情况
异常1
将notify放到wait方法前
程序无法执行，无法唤醒
异常2
代码
wait和notify方法必须要在同步块或者方法里面，且成对出现使用
先wait后notify才OK
小总结
Object类中的wait和notify方法实现线程等待和唤醒
去掉lock和unlock块
先signal后await
Condition中的线程等待和唤醒必须要在lock中
必须要先等待后唤醒，线程才能够被唤醒
Condition接口中的await后signal方法实现线程的等待和唤醒
上述两个对象Object和Condition使用的限制条件
LockSupport是用来创建锁和其他同步类的基本线程阻塞原语
LockSupport类使用了一种名为Permit（许可）的概念来做到阻塞和唤醒线程的功能，每个线程都有一个许可（permit），但与Semaphore不同的是，许可的累加上限是1。
LockSupport官方说明
https://doc.qzxdp.cn/jdk/17/zh/api/java.base/java/util/concurrent/locks/LockSupport.html
park（）/park(Object blocker)
阻塞当前线程/阻塞传入的具体线程
阻塞
调用unpark(thread)方法后，就会将thread线程的许可证permit发放，会自动唤醒park线程，即之前阻塞中的LockSupport.park（）方法会立即返回
Unpark（Thread thread）
唤醒处于阻塞状态的指定线程
唤醒
主要方法
正常+无锁块要求
之前错误的先唤醒后等待，LockSupport照样支持
成双成对要牢记
LockSupport是用来创建锁和其他同步类的基本线程阻塞原语。
Locksupport是一个线程阻寒工具类，所有的方法都是静态方法，可以让线程在任意位置阻塞，阻塞之后也有对应的唤醒方法。归根结底，LockSupport调用的Unsafe中的native代码。
LockSupport和每个使用它的线程都有一个许可(permit)关联。
LockSupport 提供park()和unpark()方法实现阻塞线程和解除线程阻塞的过程
线程阻塞需要消耗凭证(permit)，这个凭证最多只有1个。当调用 park方法时*如果有凭证，则会直接消耗掉这个凭证然后正常退出:*如果无凭证，就必须阻塞等待凭证可用:而unpark则相反，它会增加一个凭证，但凭证最多只能有1个，累加无效。
形象的理解
重点说明（重要）
因为unpark获得了一个凭据，之后再调用park方法，就可以名正言顺的凭证消费，故不会阻塞
先发放凭证后续可以畅通无阻
为什么可以突破wait/notify的原有调用顺序
因为凭证的数量最多为1，连续调用两次unpark和调用一次unpark效果一样，只会增加一个凭证；而调用两次park却需要消费两个凭证，证不够，不能放行。
为什么唤醒两次后阻塞两次，但最终结果还会阻塞线程
LockSupport类中的park等待和unpark唤醒
线程等待唤醒机制
5、LockSupport与线程中断
你知道什么是Java内存模型JMM吗？
JMM与volatile他们两个之间的关系？
JMM有哪些特性or它的三大特性是什么？
为什么要有JMM？它为啥出现？作用和功能是什么？
大厂面试题
重点：屏蔽掉各种硬件和操作系统内存的访问差异
计算机硬件存储体系
Java内存模型Java Memory ModelJMM(Java内存模型Java Memory Model，简称JMM)本身是一种抽象的概念并不真实存在它仅仅描述的是一组约定或规范，通过这组规范定义了程序中(尤其是多线程)各个变量的读写访问方式并决定一个线程对共享变量的写入何时以及如何变成对另一个线程可见，关键技术点都是围绕多线程的原子性、可见性和有序性展开的。原则:JMM的关键技术点都是围绕多线程的原子性、可见性和有序性展开的能干嘛?1 通过JMM来实现线程和主内存之间的抽象关系2 屏蔽各个硬件平台和操作系统的内存访问差异以实现让Java程序在各种平台下都能达到一致的内存访问效果。
Java内存模型Java Memory Model
线程脏读
可见性
同一个操作不可打断，即多线程环境下，操作不能被其他线程干扰
原子性
简单案例
是什么对于一个线程的执行代码而言，我们总是习惯性认为代码的执行总是从上到下，有序执行。但为了提升性能，编译器和处理器通常会对指令序列进行重新排序。Java规范规定JVM线程内部维持顺序化语义，即只要程序的最终结果与它顺序化执行的结果相等，那么指令的执行顺序可以与代码顺序不致，此过程叫指令的重排序。
优缺点
有序性
JMM规范下，三大特性
读取过程由于JM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，工作内存是每个线程的私有数据区域，而java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到的线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成，其简要访问过程如下图:
1、线程之间的共享变量存储在主内存中（从硬件角度来说就是内存条）
2、每个线程都有一个私有的本地工作内存，本地工作内存中存储了该线程用来读/写共享变量的副本（从硬件角度来说就是CPU的缓存，比如寄存器L1、L2、L3缓存等）
JMM定义了线程和主内存之间的抽象关系
我们定义的所有共享变量都存储在物理内存中
每个线程都有自己独立的工作内存，里面保存该线程使用到的变量的副本（主内存中该变量的一份拷贝）
线程对共享变量所有的操作都必须先在线程自己的工作内存中进行后写回主内存，不能直接从主内存中读写（不能越级）
不同线程之间也无法直接访问其他线程的工作内存中的变量，线程间变量值的传递需要通过主内存来进行（同级不能互相访问）
JMM规范下，多线程对变量的读写过程
在JMM中如果一个操作执行的结果需要对另一个操作可见性或者代码重排序，那么这两个操作之间必须存在happens-before(先行发生)原则。逻辑上的先后关系
问题
x、y案例说明
先行发生原则说明
值日的调换班
1+2+3=3+2+1
两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。
happens-before总原则
一个线程内，按照代码顺序，写在前面的操作先行发生于写在后面的操作
前一个操作的结果可以被后续的操作获取。讲白点就是前面一个操作把变量X赋值为1，那后面一个操作肯定能知道X已经变成了1。
加深说明
1 次序规则
一个unLock操作先行发生于后面（这里的“后面”是指时间上的先后）对同一个锁的lock操作
2 锁定规则
对一个volatile变量的写操作先行发生于后面对这个变量的读操作，前面的写对后面的读是可见的，这里的“后面”同样是指时间上的先后
3 volatile变量规则
如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C
4 传递规则
线程对象的start()方法先行于发生于此线程的每个动作
5 线程启动规则（Thread start rule）
对线程interrupt方法的调用先行发生于被中断线程的代码检测到中断事件的发生
可以通过Thread.interrupted检测到是否发生中断
也就是说你要先调用interrupt方法设置过中断标志位，我才能检测到中断发送
6 线程中断规则（Thread Interruption rule）
线程中的所有操作都发生于此线程的终止检测，我们可以通过isAlive（）等手段检测线程是否已经终止执行
7 线程终止规则（Thread Termination rule）
一个对象的初始化完成（构造函数执行结束），先行于发生于它的finalize（）方法开始
finalize方法是回收之前执行的方法
直白点
8 对象终结规则（Finalizer Rule）
happen-before之8条
在java语言里面，Happens-before的语义本质上也是一种可见性
A Happens-before B 意味着A发生过的事情对B来说是可见的，无论A事件和B事件是否发生在同一个线程里
一部分是面向我们程序员提供的，也就是happens-before规则，它通俗易懂的向我们程序员阐述了一个强内存模型，我们只要理解happens-before规则，就可以编写并发安全的程序了
另一部分是针对JMM实现的，为了尽可能少的对编译器和处理器做约束从而提高性能，JMM在不影响程序执行结果的前提下对其不做要求，即允许优化重排序。我们只需要关注前者就好了，也就是理解happens-before规则即可，其它繁杂的内容有JMM规范结合操作系统给我们搞定，我们只写好代码就行
JMM的设计
happens-before-小总结
把getter/setter方法都定义为synchronized方法
修复01（并发量小可以用这个）
把Value定义为volatile变量，由于setter方法对value的修改不依赖value的原值，满足volatile关键字使用场景
修复02
修复方式
案例说明
JMM规范下，多线程先行发生原则之Happens-before·
6、Java内存模型之JMM
特点
当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中。
当读到一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，重新回到主内存中读取最新共享变量
所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取
volatile语义
内存屏障Memory
volatile如何可以保证可见性和有序性？？?
被volatile修饰的变量有2个大特点
没有管控，顺序难保
设定规则禁止乱序
写完后立即刷新回主内存并及时发出通知，大家可以去主内存拿最新版，前面的修改对面所有的线程可见
可见
重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序不存在数据依赖关系，可以重排序;
存在数据依赖关系，禁止重排序，但重排后的指令绝对不能改变原有的串行语义!这点在并发设计中必须要重点考虑!
重排序
有序（禁止重排）
再说volatile两个大特性
先说生活case
内存屏障(也称内存栅栏，屏障指令等，是一类同步屏障指令是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作，避免代码重排序。
内存屏障其实就是一种JVM指令，java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatie实现了java内存模型中的可见性和有序性(禁重排)，但volatile无法保证原子性。
内存屏障之前的所有写操作都要回写到主内存，
内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)。
写屏障(Store Memory Barier):告诉处理器在写屏障之前将所有存储在缓存(store buferes)中的数据同步到主内存。也就是说当看到Store屏障指令，就必须把该指令之前所有写入指令执行完毕才能继续往下执行。
读屏障(Load Memory Barier):处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。
线程、主内存、工作内存三者的交互关系
一句话:对一个volatie变量的写，先行发生于任意后续对这个volatile变量的读，也叫写后读。
因此重排序时，不允许把内存屏障之后的指令重排序到内存屏障之前。
happens-brfore先行发生原则，类似接口规范的落地
一句话
在读指令之前插入读屏障，让工作内存或CPU高速缓存当中的缓存数据失效，重新回到主内存中获取最新数据
读屏障
在写指令之后插入写屏障，强制把写缓冲区的数据刷回到主内存中
写屏障
粗分2种
java中的调用接口
unsafe。cpp
C++代码
Load1; LoadLoad; Load2
保证load1的读取操作在load2及后续读取操作之前执行
LoadLoad
Store1; StoreStore; Store2
在store2及其后的写操作执行前，保证store1的写操作已刷新到主内存
StoreStore
Load1; LoadStore; Store2
在stroe2及其后的写操作执行前，保证load1的读操作已读取结束
LoadStore
Store1; StoreLoad; Load2
保证store1的写操作已刷新到主内存之后，load2及其后的读操作才能执行
StoreLoad
屏障类型
细分4种
内存屏障分类
通过内存屏障来禁止重排序
禁止重排
1重排序有可能影响程序的执行和实现，因此，我们有时候希望告诉JVM你别“自作聪明”给我重排序，我这里不需要排序，听主人的。2 对于编译器的重排序，JMM会根据重排序的规则，禁止特定类型的编译器重排序。3 对于处理器的重排序，Java编译器在生成指令序列的适当位置，插入内存屏障指令，来禁止特定类型的处理器排序。
什么叫指令重排
细致重述
内存屏障（面试重点）
volatile特性
如何正确使用volatile
本章最后的小总结
7、volatile与JMM
从start一个线程说起
synchronized
一把锁
是在同一实体上的多个事件，
是在一台机器上“同时”处理多个任务
同一时刻，其实是只有一个事情再发生
并发
是在不同实体上的多个事件，
是在多台处理器上同时处理多个任务，
同一时刻，大家都在做事情，你做你的，我做我的，各干各的。
并行
并发VS并行
2个并
在系统中运行的一个应用程序，每个进程都有它自己的内存空间和系统资源
进程
也被称为轻量级进程，在同一个进程内会有1个或多个线程，是大多数操作系统进行时序调度的基本单元。
线程
Monitor（锁），也就是我们平时所说的锁。Monitor其实是一种同步机制，它的义务是保证（同一时间）只有一个线程可以访问被保护的数据和代码，JVM中同步是基于进入和退出监视器（Monitor管程对象）来实现的，每个对象实例都会有一个Monitor对象，Monitor对象和Java对象一同创建并销毁，底层由C++语言实现。
管程
3个程
java多线程相关概念
一般情况下不做特别说明，默认都是用户线程。
是系统的工作线程，它会完成这个程序需要完成的业务操作。
用户线程（User Thread）
是一种特殊的线程为其他线程服务的，在后台默默地完成一些系统性的任务，比如垃圾回收线程就是最典型的例子。
守护线程作为一个服务线程，没有服务对象就没有必要继续运行了，如果用户线程全部结束了，意味着程序需要完成的业务操作已经结束了，系统可以退出了。所以假如当系统只剩下守护线程的时候，守护线程伴随着JVM一同结束工作。
true表示是守护线程
false表示是用户线程
线程的daemon属性
thread.setDaemon(true)必须在thread.start()之前设置，否则会跑出一个legalThreadStateException异常!你不能把正在运行的常规线程设置为守护线程。
守护线程（Daemon Thread）
用户线程和守护线程
基础知识
取消任务的执行、郑断任务是否被Future接囗(FutureTask实现类)定义了操作异步任务执行些方法，如获取异步任务的执行结果取消、判断任务执行是否完毕等。
举例上课买水案例给大家说明补充。。。。。。
比如主线程让一个子线程去执行任务，子线程可能比较耗时，启动子线程开始执行任务后，过了一会才去获取子任务的执行结果或变更的任务状态。主线程就去做其他事情了，忙其它事情或者先执行完，
Future接口理论知识复习
Future是Java5新加的一个接口，它提供了一种异步并行计算的功能。如果主线程需要执行一个很耗时的计算任务，我们就可以通过future把这个任务放到异步线程中执行主线程继续处理其他任务或者先行结束，再通过Future获取计算结果。代码说话:Runnable接日Callable接口uture接口和FutureTask实现类目的:异步多线程任务执行且返回有结果，三个特点:多线程/有返回/异步任务(班长为老师去买水作为新启动的异步多线程任务且买到水有结果返回)
三个特点:多线程/有返回/异步任务
关于Future的使用
future+线程池异步多线程任务配合，能显著提高程序的执行效率
代码展示，线程池结合Future
优点
get（）阻塞
缺点
Future编码实战的优缺点分析
Future接口常用实现类FutureTask异步任务
CompletableFuture的出现
接口CompletionStage是什么
CompletableFuture类
源码分析
CompletableFuture为啥出现
public static CompletableFuture<Void> runAsync(Runnable runnable)
runAsync 无 返回值
public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier)
supplyAsync 有 返回值
没有指定Executor的方法，直接使用默认的ForkJoinPool.commonPool()作为它的线程池执行异步代码。
如果指定线程池，则使用我们自定义的或者特别指定的线程池执行异步代码
上述Executor参数说明
code通用演示，减少轮询和阻塞
核心的四个静态方法，来创建一个异步任务
CompletableFuture对Future的改进
案例精讲：从电商网站的比价需求说开去
public T get()
public T join()
public T getNow(T valueIfAbsent)
获取结果
public boolean complete(T value)
主动触发计算
获得结果和触发计算
计算结果存在依赖关系，这两个线程串行化
由于存在依赖关系（当前步错，不走下一步），当前步骤有异常的话就叫停。
异常相关
thenApply
有异常也可也往下走一步，根据带的异常参数可以进一步处理。
handle
对计算结果进行处理
接受任务的处理结果，并消费处理，无返回结果
thenAccept
在任务A执行完执行B，并且B不需要A的结果
thenRun
任务A执行完，执行任务B，B需要A的结果，但是任务B无返回值
任务A执行完执行B，B需要A的结果，同时任务B有返回值
Code之任务之间的顺序执行
对比补充
以thenRun和thenRunAsync为例，有什么区别？
CompletableFuture和线程池说明
对计算结果进行消费
谁快用谁
applyToEither
对计算速度进行选用
两个CompletionStage任务都完成后，最终能把两个任务的结果一起交给thenCombine来处理先
完成的先等着，等待其它分支任务
标准版
thenCombine
对结算结果进行合并
CompletableFuture常用方法
3.CompletableFuture
适合写操作多的场景，先加锁可以保证写操作时数据正确
显式的锁定之后再操作同步资源
悲观锁
适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升。
乐观锁则直接操作同步资源，是一种无锁算法，得之我幸不得我命，再重来就行
佛系
一句话总结
采用version制
采用CAS
乐观锁一般有两种实现方式：
乐观锁
乐观锁和悲观锁
【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 RPC 方法。
阿里要求
锁的相关的8种案例演示code
持有的锁是类
静态同步方法
持有的锁是对象
普通同步方法
持有的锁是synchronized（obj）中的参数
同步代码块
Synchronized有三种应用方式
-c 对代码进行反汇编
javap -v ***.class 文件反编译
-v -verbose 输出附加信息（包括行号、本地变量表、反汇编等详细信息）
假如你需要更多的信息
javap -c ***.class文件反编译
实现使用的是monitorenter和monitorexit指令
为了避免异常导致一直持有锁的情况
一般是
极端情况是方法中带有一个异常的抛出的情况
一定是monitorenter和monitorexit，一个enter对两个exit的比例吗？
synchronized 同步代码块
调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否被设置。如果设置了，执行线程会将先持有monitor锁，然后再执行方法，最后在方法完成（无论是正常完成还是非正常完成）时释放monitor
synchronized 普通同步方法
synchronized 静态同步方法
从字节码角度分析Synchronized实现
在Hostpot虚拟机中，monistor采用ObjectMonitor实现
ObjectMonitor.java->ObjectMonitor.cpp->objectMonitor.hpp
objectMonitor.hpp
每个对象天生都带一个对象监视器
每一个被锁住的对象都会和Monitor关联起来
C++源码解读
面试题：为什么任何一个对象都可以成为一个锁
管程 (英语:Monitors，也称为监视器)是一种程序结构，结构内的多个子程序(对象或模块)形成的多个工作线程互斥访问共享资源。这些共享资源一般是硬件设各或一群变量。对共享变量能够进行的所有操作集中在一个模块中。(把信号量及其操作原语“封装”在一个对象内部)管程实现了在一个时间点，最多只有一个线程在执行管程的某个子程序。管程提供了一种机制，管程可以看做一个软件模块，它是将共享的变量和对于这些共享变量的操作封装起来，形成一个具有一定接口的功能模块，进程可以调用管程来实现进程级别的并发控制。
什么管程monitor
反编译Synchronized锁的是什么
对于synchronized关键字
通过8种情况演示锁运行案例，看看我们到底锁的是什么？
从ReentrantLock卖票demo演示公平和非公平现象
关于公平锁和非公平锁的定义
为什么会有公平锁/非公平锁的设计？为什么默认非公平
如果为了更高的吞吐量，很显然非公平锁是比较合适的，因为节省很多线程切换时间，吞吐量自然就上去了
否则就用公平锁，公平使用
什么时候用公平？什么时候用非公平？
何为公平锁和非公平锁？
AQS，实现公平锁和非公平锁的原理
预埋伏AQS
公平锁和非公平锁
如果是1个有 synchronized 修饰的递归调用方法，程序第2次#入被自己阻塞了岂不是天大的笑话，出现了作茧自缚，所以Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。
可重入锁又名递归锁是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁(前提，锁对象得是同一个对象)，不会因为之前已经获取过还没释放而阻塞。
可：可以
重：再次
入：进入
锁：同步锁
进入同步域（即同步代码块/方法或显式锁锁定的代码）
进入什么？
一个线程中的多个流程可以获取同一把锁，持有这把同步锁可以再次进入。
自己可以获取自己的内部锁
“可重入锁”这四个字分开解释
同步块
同步方法
隐式锁（即synchronized关键字使用的锁）默认是可重入锁
Synchronized的重入的实现机理
显式锁也有ReentrantLock这样的可重入锁。
可重入锁的种类
可重入锁（又名递归锁）
请写一个死锁的代码case
jps -l
jstack进程编号
java自带的原生命令
jconsole
图形化
如何排查死锁
死锁及排查
写锁（独占锁）/读锁（共享锁）
自旋锁spinLock
无锁->独占锁->读写锁->邮戳锁
无锁->偏向锁->轻量级锁->重量锁
指针指向monitor对象(也称为管程或监视器锁)的起始地址。每个对象都存在着一个monitor与之关联，当一个 monitor 被某个线程持有后，它便处于锁定状态。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下(位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的)
4、java的锁
尚硅谷JUC并发编程
收藏
收藏
0 条评论
回复 删除
下一页
