锐客网

  1. 首页 > 生活百科 > it技术 > >

java自旋锁代码 jvm 自旋锁

IT技术线程

Java中有哪些锁，区别是什么【1】公平所和非公平所 。
【java自旋锁代码 jvm 自旋锁】公平锁：是指按照申请锁的顺序来获取锁，
非公平所：线程获取锁的顺序不一定按照申请锁的顺序来的 。
//默认是不公平锁 ， 传入true为公平锁 ， 否则为非公平锁
ReentrantLock reentrantLock =new ReetrantLock();
1
2
【2】共享锁和独享锁
独享锁：一次只能被一个线程所访问
共享锁：线程可以被多个线程所持有 。
ReadWriteLock 读锁是共享锁，写锁是独享锁 。
【3】乐观锁和悲观锁 。
乐观锁：对于一个数据的操作并发 ， 是不会发生修改的 。在更新数据的时候，会尝试采用更新 ， 不断重入的方式，更新数据 。
悲观锁：对于同一个数据的并发操作，是一定会发生修改的 。因此对于同一个数据的并发操作 ， 悲观锁采用加锁的形式 。悲观锁认为，不加锁的操作一定会出问题，
【4】分段锁
1.7及之前的concurrenthashmap 。并发操作就是分段锁，其思想就是让锁的粒度变小 。
【5】偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁 。降低获取锁的代价
轻量级锁
重量级锁
【6】自旋锁
自旋锁
说说java锁有哪些种类，以及区别锁作为并发共享数据，保证一致性java自旋锁代码的工具，在JAVA平台有多种实现(如 synchronized 和 ReentrantLock等等 )。这些已经写好提供java自旋锁代码的锁为我们开发提供java自旋锁代码了便利，但是锁的具体性质以及类型却很少被提及 。本系列文章将分析JAVA下常见的锁名称以及特性，为大家答疑解惑 。
1、自旋锁
自旋锁是采用让当前线程不停地的在循环体内执行实现的，当循环的条件被其他线程改变时 才能进入临界区 。如下
01public class SpinLock {
02
03private AtomicReferenceThread sign =newAtomicReference();
04
05public void lock(){
06Thread current = Thread.currentThread();
07while(!sign .compareAndSet(null, current)){
08}
09}
10
11public void unlock (){
12Thread current = Thread.currentThread();
13sign .compareAndSet(current, null);
14}
15}
使用了CAS原子操作，lock函数将owner设置为当前线程，并且预测原来的值为空 。unlock函数将owner设置为null，并且预测值为当前线程 。
当有第二个线程调用lock操作时由于owner值不为空，导致循环一直被执行，直至第一个线程调用unlock函数将owner设置为null ， 第二个线程才能进入临界区 。
由于自旋锁只是将当前线程不停地执行循环体，不进行线程状态的改变，所以响应速度更快 。但当线程数不停增加时，性能下降明显，因为每个线程都需要执行 ， 占用CPU时间 。如果线程竞争不激烈，并且保持锁的时间段 。适合使用自旋锁 。
注：该例子为非公平锁 ， 获得锁的先后顺序，不会按照进入lock的先后顺序进行 。
Java锁的种类以及辨析（二）：自旋锁的其他种类
锁作为并发共享数据，保证一致性的工具，在JAVA平台有多种实现(如 synchronized 和 ReentrantLock等等 )。这些已经写好提供的锁为我们开发提供了便利，但是锁的具体性质以及类型却很少被提及 。本系列文章将分析JAVA下常见的锁名称以及特性，为大家答疑解惑 。
2.自旋锁的其他种类
上篇我们讲到了自旋锁，在自旋锁中 另有三种常见的锁形式:TicketLock ，CLHlock 和MCSlock
Ticket锁主要解决的是访问顺序的问题，主要的问题是在多核cpu上
01package com.alipay.titan.dcc.dal.entity;
02
03import java.util.concurrent.atomic.AtomicInteger;
04
05public class TicketLock {
06private AtomicIntegerserviceNum = new AtomicInteger();
07private AtomicIntegerticketNum= new AtomicInteger();
08private static final ThreadLocalInteger LOCAL= new ThreadLocalInteger();
09
10public void lock() {
11int myticket = ticketNum.getAndIncrement();
12LOCAL.set(myticket);
13while (myticket != serviceNum.get()) {
14}
15
16}
17
18public void unlock() {
19int myticket = LOCAL.get();
20serviceNum.compareAndSet(myticket, myticket1);
21}
22}
每次都要查询一个serviceNum 服务号 ， 影响性能（必须要到主内存读取，并阻止其他cpu修改） 。
CLHLock 和MCSLock 则是两种类型相似的公平锁，采用链表的形式进行排序，
01importjava.util.concurrent.atomic.AtomicReferenceFieldUpdater;
02
03public class CLHLock {
04public static class CLHNode {
05private volatile boolean isLocked = true;
06}
07
08@SuppressWarnings("unused")
09private volatileCLHNodetail;
10private static finalThreadLocalCLHNodeLOCAL= new ThreadLocalCLHNode();
11private static finalAtomicReferenceFieldUpdaterCLHLock, CLHNode UPDATER = AtomicReferenceFieldUpdater.newUpdater(CLHLock.class,
12CLHNode.class,"tail");
13
14public void lock() {
15CLHNode node = new CLHNode();
16LOCAL.set(node);
17CLHNode preNode = UPDATER.getAndSet(this, node);
18if (preNode != null) {
19while (preNode.isLocked) {
20}
21preNode = null;
22LOCAL.set(node);
23}
24}
25
26public void unlock() {
27CLHNode node = LOCAL.get();
28if (!UPDATER.compareAndSet(this, node,null)) {
29node.isLocked = false;
30}
31node = null;
32}
33}
CLHlock是不停的查询前驱变量，导致不适合在NUMA 架构下使用（在这种结构下，每个线程分布在不同的物理内存区域）
MCSLock则是对本地变量的节点进行循环 。不存在CLHlock 的问题 。
01importjava.util.concurrent.atomic.AtomicReferenceFieldUpdater;
02
03public class MCSLock {
04public static class MCSNode {
05volatile MCSNode next;
06volatile boolean isLocked = true;
07}
08
09private static finalThreadLocalMCSNodeNODE= new ThreadLocalMCSNode();
10@SuppressWarnings("unused")
11private volatileMCSNodequeue;
12private static finalAtomicReferenceFieldUpdaterMCSLock, MCSNode UPDATER = AtomicReferenceFieldUpdater.newUpdater(MCSLock.class,
13MCSNode.class,"queue");
14
15public void lock() {
16MCSNode currentNode = new MCSNode();
17NODE.set(currentNode);
18MCSNode preNode = UPDATER.getAndSet(this, currentNode);
19if (preNode != null) {
20preNode.next = currentNode;
21while (currentNode.isLocked) {
22
23}
24}
25}
26
27public void unlock() {
28MCSNode currentNode = NODE.get();
29if (currentNode.next == null) {
30if (UPDATER.compareAndSet(this, currentNode, null)) {
31
32} else {
33while (currentNode.next == null) {
34}
35}
36} else {
37currentNode.next.isLocked = false;
38currentNode.next = null;
39}
40}
41}
自旋锁和互斥锁的区别 java中lock Syntronized区别自旋锁(Spin lock)
自旋锁与互斥锁有点类似 ， 只是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是
否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名 。其作用是为了解决某项资源的互斥使用 。因为自旋锁不会引起调用者睡眠，所以自旋锁的效率远
高于互斥锁 。虽然它的效率比互斥锁高，但是它也有些不足之处：
1、自旋锁一直占用CPU，他在未获得锁的情况下，一直运行－－自旋，所以占用着CPU，如果不能在很短的时 间内获得锁，这无疑会使CPU效率降低 。
2、在用自旋锁时有可能造成死锁，当递归调用时有可能造成死锁 ， 调用有些其他函数也可能造成死锁，如 copy_to_user()、copy_from_user()、kmalloc()等 。
因此我们要慎重使用自旋锁，自旋锁只有在内核可抢占式或SMP的情况下才真正需要，在单CPU且不可抢占式的内核下，自旋锁的操作为空操作 。自旋锁适用于锁使用者保持锁时间比较短的情况下 。
两种锁的加锁原理
互斥锁：线程会从sleep（加锁）——running（解锁），过程中有上下文的切换，cpu的抢占，信号的发送等开销 。
自旋锁：线程一直是running(加锁——解锁)，死循环检测锁的标志位 ， 机制不复杂 。
互斥锁属于sleep-waiting类型的锁 。例如在一个双核的机器上有两个线程(线程A和线程B)，它们分别运行在Core0和
Core1上 。假设线程A想要通过pthread_mutex_lock操作去得到一个临界区的锁，而此时这个锁正被线程B所持有，那么线程A就会被阻塞
(blocking)，Core0 会在此时进行上下文切换(Context
Switch)将线程A置于等待队列中，此时Core0就可以运行其他的任务(例如另一个线程C)而不必进行忙等待 。而自旋锁则不然，它属于busy-waiting类型的锁，如果线程A是使用pthread_spin_lock操作去请求锁，那么线程A就会一直在
Core0上进行忙等待并不停的进行锁请求，直到得到这个锁为止 。
两种锁的区别
互斥锁的起始原始开销要高于自旋锁，但是基本是一劳永逸，临界区持锁时间的大小并不会对互斥锁的开销造成影响，而自旋锁是死循环检测 ， 加锁全程消耗cpu，起始开销虽然低于互斥锁，但是随着持锁时间，加锁的开销是线性增长 。
两种锁的应用
互斥锁用于临界区持锁时间比较长的操作，比如下面这些情况都可以考虑
1 临界区有IO操作
2 临界区代码复杂或者循环量大
3 临界区竞争非常激烈
4 单核处理器
至于自旋锁就主要用在临界区持锁时间非常短且CPU资源不紧张的情况下，自旋锁一般用于多核的服务器 。
lock与Syntronized的区别
转自自：
java并发之Lock与synchronized的区别
1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
2）synchronized在发生异常时，会自动释放线程占有的锁 ， 因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到 。
5）Lock可以提高多个线程进行读操作的效率 。
在性能上来说，如果竞争资源不激烈 ， 两者的性能是差不多的 ， 而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized 。所以说，在具体使用时要根据适当情况选择 。
两者在锁的相关概念上区别：
1.可重入锁
如果锁具备可重入性，则称作为可重入锁 。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配 。举个简单的例子 ， 当一个线程执行到某个synchronized方法时 ， 比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2 。
看下面这段代码就明白了：
1
2
3
4
5
6
7
8
9
class MyClass
{
public synchronized void method1()
{
method2();
}
public synchronized void method2()
{
}
}
上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性 ， 此时线程A需要重新申请锁 。但是这就会造成一个问题 ， 因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁 。
而由于synchronized和Lock都具备可重入性，所以不会发生上述现象 。
2.可中断锁
可中断锁：顾名思义，就是可以相应中断的锁 。
在Java中，synchronized就不是可中断锁，而Lock是可中断锁 。
如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它 ， 这种就是可中断锁 。
在前面演示lockInterruptibly()的用法时已经体现了Lock的可中断性 。
3.公平锁
公平锁即尽量以请求锁的顺序来获取锁 。比如同是有多个线程在等待一个锁，当这个锁被释放时 ， 等待时间最久的线程（最先请求的线程）会获得该所 ， 这种就是公平锁 。
非公平锁即无法保证锁的获取是按照请求锁的顺序进行的 。这样就可能导致某个或者一些线程永远获取不到锁 。
在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序 。
而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁 。
看一下这2个类的源代码就清楚了：
在ReentrantLock中定义了2个静态内部类，一个是NotFairSync，一个是FairSync，分别用来实现非公平锁和公平锁 。
我们可以在创建ReentrantLock对象时，通过以下方式来设置锁的公平性：
1
ReentrantLock
lock = new ReentrantLock(true);
如果参数为true表示为公平锁 ， 为fasle为非公平锁 。默认情况下，如果使用无参构造器，则是非公平锁 。
另外在ReentrantLock类中定义了很多方法，比如：
isFair()//判断锁是否是公平锁
isLocked()//判断锁是否被任何线程获取了
isHeldByCurrentThread()//判断锁是否被当前线程获取了
hasQueuedThreads()//判断是否有线程在等待该锁
在ReentrantReadWriteLock中也有类似的方法，同样也可以设置为公平锁和非公平锁 。不过要记住，ReentrantReadWriteLock并未实现Lock接口，它实现的是ReadWriteLock接口 。
4.读写锁
读写锁将对一个资源（比如文件）的访问分成了2个锁 ， 一个读锁和一个写锁 。
正因为有了读写锁 ， 才使得多个线程之间的读操作不会发生冲突 。
ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口 。
可以通过readLock()获取读锁 ， 通过writeLock()获取写锁 。
性能比较
在JDK1.5中，synchronized是性能低效的 。因为这是一个重量级操作，它对性能最大的影响是阻塞的是实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力 。相比之下使用Java提供的Lock对象，性能更高一些 。Brian
Goetz对这两种锁在JDK1.5、单核处理器及双Xeon处理器环境下做了一组吞吐量对比的实验，发现多线程环境下，synchronized的吞吐量下降的非常严重，而ReentrankLock则能基本保持在同一个比较稳定的水平上 。但与其说ReetrantLock性能好，倒不如说synchronized还有非常大的优化余地，于是到了JDK1.6，发生了变化，对synchronize加入了很多优化措施，有自适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等 。导致在JDK1.6上synchronize的性能并不比Lock差 。官方也表示 ， 他们也更支持synchronize ， 在未来的版本中还有优化余地，所以还是提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步 。
Java锁有哪些种类，以及区别一、公平锁/非公平锁
公平锁是指多个线程按照申请锁的顺序来获取锁 。
非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁 。有可能，会造成优先级反转或者饥饿现象 。
对于Java ReentrantLock而言 ， 通过构造函数指定该锁是否是公平锁，默认是非公平锁 。非公平锁的优点在于吞吐量比公平锁大 。
对于Synchronized而言，也是一种非公平锁 。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁 。
二、可重入锁
可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁 。说的有点抽象 ， 下面会有一个代码的示例 。
对于Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁，其名字是Re entrant Lock重新进入锁 。
对于Synchronized而言,也是一个可重入锁 。可重入锁的一个好处是可一定程度避免死锁 。
synchronized void setA() throws Exception{
Thread.sleep(1000);
setB();
}
synchronized void setB() throws Exception{
Thread.sleep(1000);
}
上面的代码就是一个可重入锁的一个特点，如果不是可重入锁的话，setB可能不会被当前线程执行，可能造成死锁 。
三、独享锁/共享锁
独享锁是指该锁一次只能被一个线程所持有 。
共享锁是指该锁可被多个线程所持有 。
对于Java
ReentrantLock而言 ， 其是独享锁 。但是对于Lock的另一个实现类ReadWriteLock ， 其读锁是共享锁，其写锁是独享锁 。
读锁的共享锁可保证并发读是非常高效的，读写，写读 ，写写的过程是互斥的 。
独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法 ， 来实现独享或者共享 。
对于Synchronized而言 ， 当然是独享锁 。
四、互斥锁/读写锁
上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现 。
互斥锁在Java中的具体实现就是ReentrantLock
读写锁在Java中的具体实现就是ReadWriteLock
五、乐观锁/悲观锁
乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度 。
悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改 。因此对于同一个数据的并发操作，悲观锁采取加锁的形式 。悲观的认为，不加锁的并发操作一定会出问题 。
乐观锁则认为对于同一个数据的并发操作，是不会发生修改的 。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据 。乐观的认为，不加锁的并发操作是没有事情的 。
从上面的描述我们可以看出 ， 悲观锁适合写操作非常多的场景 ， 乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升 。
悲观锁在Java中的使用 ， 就是利用各种锁 。
乐观锁在Java中的使用，是无锁编程 ， 常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新 。
六、分段锁
分段锁其实是一种锁的设计 ， 并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作 。
我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap(JDK7与JDK8中HashMap的实现)的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表;同时又是一个ReentrantLock(Segment继承了ReentrantLock) 。
当需要put元素的时候，并不是对整个hashmap进行加锁 ， 而是先通过hashcode来知道他要放在那一个分段中 ， 然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入 。
但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计 。
分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作 。
七、偏向锁/轻量级锁/重量级锁
这三种锁是指锁的状态，并且是针对Synchronized 。在Java
5通过引入锁升级的机制来实现高效Synchronized 。这三种锁的状态是通过对象监视器在对象头中的字段来表明的 。
偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁 。降低获取锁的代价 。
轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞 ， 提高性能 。
重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁 。重量级锁会让其他申请的线程进入阻塞 ， 性能降低 。
八、自旋锁
在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗 ， 缺点是循环会消耗CPU 。
典型的自旋锁实现的例子，可以参考自旋锁的实现
java 哪个锁是非重入的读写锁 ReadWriteLock读写锁维护java自旋锁代码了一对相关java自旋锁代码的锁java自旋锁代码，一个用于只读操作，一个用于写入操作 。只要没有writer ， 读取锁可以由多个reader线程同时保持 。写入锁是独占java自旋锁代码的 。
互斥锁一次只允许一个线程访问共享数据 ， 哪怕进行的是只读操作；读写锁允许对共享数据进行更高级别的并发访问：对于写操作，一次只有一个线程（write线程）可以修改共享数据，对于读操作，允许任意数量的线程同时进行读取 。
与互斥锁相比，使用读写锁能否提升性能则取决于读写操作期间读取数据相对于修改数据的频率 ， 以及数据的争用——即在同一时间试图对该数据执行读取或写入操作的线程数 。
读写锁适用于读多写少的情况 。
可重入读写锁 ReentrantReadWriteLock
属性ReentrantReadWriteLock 也是基于 AbstractQueuedSynchronizer 实现的，它具有下面这些属性（来自Java doc文档）：
* 获取顺序：此类不会将读取者优先或写入者优先强加给锁访问的排序 。
* 非公平模式（默认）：连续竞争的非公平锁可能无限期地推迟一个或多个reader或writer线程，但吞吐量通常要高于公平锁 。
* 公平模式：线程利用一个近似到达顺序的策略来争夺进入 。当释放当前保持的锁时，可以为等待时间最长的单个writer线程分配写入锁，如果有一组等待时间大于所有正在等待的writer线程的reader，将为该组分配读者锁 。
* 试图获得公平写入锁的非重入的线程将会阻塞 ， 除非读取锁和写入锁都自由（这意味着没有等待线程） 。
* 重入：此锁允许reader和writer按照 ReentrantLock 的样式重新获取读取锁或写入锁 。在写入线程保持的所有写入锁都已经释放后，才允许重入reader使用读取锁 。
writer可以获取读取锁，但reader不能获取写入锁 。
* 锁降级：重入还允许从写入锁降级为读取锁 ， 实现方式是：先获取写入锁，然后获取读取锁 ， 最后释放写入锁 。但是，从读取锁升级到写入锁是不可能的 。
* 锁获取的中断：读取锁和写入锁都支持锁获取期间的中断 。
* Condition 支持：写入锁提供了一个 Condition 实现，对于写入锁来说 ， 该实现的行为与 ReentrantLock.newCondition() 提供的Condition 实现对 ReentrantLock 所做的行为相同 。当然，此 Condition 只能用于写入锁 。
读取锁不支持 Condition，readLock().newCondition() 会抛出 UnsupportedOperationException 。
* 监测：此类支持一些确定是读取锁还是写入锁的方法 。这些方法设计用于监视系统状态，而不是同步控制 。
实现AQS 回顾在之前的文章已经提到，AQS以单个 int 类型的原子变量来表示其状态，定义了4个抽象方法（ tryAcquire(int)、tryRelease(int)、tryAcquireShared(int)、tryReleaseShared(int)，前两个方法用于独占/排他模式，后两个用于共享模式 ）留给子类实现，用于自定义同步器的行为以实现特定的功能 。
对于 ReentrantLock ， 它是可重入的独占锁，内部的 Sync 类实现了 tryAcquire(int)、tryRelease(int) 方法，并用状态的值来表示重入次数 ， 加锁或重入锁时状态加 1，释放锁时状态减 1，状态值等于 0 表示锁空闲 。
对于 CountDownLatch，它是一个关卡，在条件满足前阻塞所有等待线程 ， 条件满足后允许所有线程通过 。内部类 Sync 把状态初始化为大于 0 的某个值，当状态大于 0 时所有wait线程阻塞 ， 每调用一次 countDown 方法就把状态值减 1，减为 0 时允许所有线程通过 。利用了AQS的共享模式 。
现在，要用AQS来实现 ReentrantReadWriteLock 。
一点思考问题
* AQS只有一个状态，那么如何表示 多个读锁 与 单个写锁 呢？
* ReentrantLock 里，状态值表示重入计数 ， 现在如何在AQS里表示每个读锁、写锁的重入次数呢？
* 如何实现读锁、写锁的公平性呢？
关于java自旋锁代码和jvm 自旋锁的介绍到此就结束了 ， 不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站 。

    推荐阅读


    上一篇：如何禁用服务器端口？ 怎么把服务器端口禁用

    下一篇：看主播直播录屏声音小，直播和录音声特别小