Continuez à créer, accélérez la croissance ! C'est le 7ème jour de ma participation au "Nuggets Daily New Plan · June Update Challenge", cliquez pour voir les détails de l'événement
1 file d'attente de blocage
1.1 File d'attente
Une file d'attente est un type spécial de table linéaire. La particularité est qu'elle n'autorise les suppressions qu'au début de la table et les opérations d'insertion à l'arrière de la table. Comme les piles, les files d'attente sont une opération soumise à la table linéaire des contraintes. La fin qui effectue l'opération d'insertion est appelée la fin de la file d'attente, et la fin qui effectue l'opération de suppression est appelée la tête de la file d'attente.
L'insertion d'un élément de file d'attente dans la file d'attente est appelée mise en file d'attente, et la suppression d'un élément de file d'attente de la file d'attente est appelée retrait de la file d'attente. Étant donné que la file d'attente ne peut être insérée qu'à une extrémité et supprimée à l'autre extrémité, seuls les éléments qui entrent dans la file d'attente en premier peuvent être supprimés de la file d'attente en premier, de sorte que la file d'attente est également appelée premier entré, premier sorti (FIFO— premier entré premier sorti) tableau linéaire.
1.2 Qu'est-ce qu'une file d'attente de blocage
1) Méthode d'insertion qui prend en charge le blocage : cela signifie que lorsque la file d'attente est pleine, la file d'attente bloquera le thread qui insère des éléments jusqu'à ce que la file d'attente soit pleine.
2) Prise en charge de la méthode de suppression du blocage : cela signifie que lorsque la file d'attente est vide, le thread qui obtient l'élément attendra que la file d'attente devienne non vide.
L'utilisation des modèles de producteur et de consommateur dans la programmation concurrente peut résoudre la plupart des problèmes de concurrence. Ce mode améliore la vitesse globale de traitement des données du programme en équilibrant la capacité de travail du thread producteur et du thread consommateur.
Dans le monde des threads, le producteur est le thread qui produit des données et le consommateur est le thread qui consomme des données. Dans le développement multithread, si la vitesse de traitement du producteur est rapide et la vitesse de traitement du consommateur est lente, le producteur doit attendre que le consommateur ait terminé le traitement avant de continuer à produire des données. De la même manière, si la puissance de traitement du consommateur est supérieure à celle du producteur, alors le consommateur doit attendre le producteur.
Pour résoudre ce problème de capacité de production et de consommation déséquilibrées, il existe un modèle producteur-consommateur. Le schéma producteur-consommateur résout le problème du couplage fort entre producteurs et consommateurs à travers un contenant. Les producteurs et les consommateurs ne communiquent pas directement entre eux, mais communiquent via des files d'attente de blocage. Par conséquent, une fois que les producteurs ont produit des données, ils n'ont pas besoin d'attendre que les consommateurs les traitent, mais les envoient directement dans des files d'attente de blocage. Les consommateurs ne demandent pas aux producteurs de données, mais elles sont extraites directement de la file d'attente de blocage, qui équivaut à un tampon, équilibrant les capacités de traitement des producteurs et des consommateurs.
Les files d'attente bloquantes sont souvent utilisées dans les scénarios producteur et consommateur. Le producteur est le thread qui ajoute des éléments à la file d'attente, et le consommateur est le thread qui prend les éléments de la file d'attente. Une file d'attente de blocage est un conteneur que les producteurs utilisent pour stocker des éléments et que les consommateurs utilisent pour obtenir des éléments.
- 抛出异常：当队列满时，如果再往队列里插入元素，会抛出IllegalStateException（"Queuefull"）异常。当队列空时，从队列里获取元素会抛出NoSuchElementException异常。
- 返回特殊值：当往队列插入元素时，会返回元素是否插入成功，成功返回true。如果是移除方法，则是从队列里取出一个元素，如果没有则返回null。
- 一直阻塞：当阻塞队列满时，如果生产者线程往队列里put元素，队列会一直阻塞生产者线程，直到队列可用或者响应中断退出。当队列空时，如果消费者线程从队列里take元素，队列会阻塞住消费者线程，直到队列不为空。
- 超时退出：当阻塞队列满时，如果生产者线程往队列里插入元素，队列会阻塞生产者线程一段时间，如果超过了指定的时间，生产者线程就会退出。
1.3常用阻塞队列
ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列。LinkedBlockingQueue：一个由链表结构组成的有界阻塞队列。PriorityBlockingQueue：一个支持优先级排序的无界阻塞队列。DelayQueue：一个使用优先级队列实现的无界阻塞队列。SynchronousQueue：一个不存储元素的阻塞队列。LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。
以上的阻塞队列都实现了BlockingQueue接口，也都是线程安全的。
有界无界
有界队列就是长度有限，满了以后生产者会阻塞，无界队列就是里面能放无数的东西而不会因为队列长度限制被阻塞，当然空间限制来源于系统资源的限制，如果处理不及时，导致队列越来越大越来越大，超出一定的限制致使内存超限，操作系统或者JVM帮你解决烦恼，直接把你 OOM kill 省事了。
无界也会阻塞，为何？因为阻塞不仅仅体现在生产者放入元素时会阻塞，消费者拿取元素时，如果没有元素，同样也会阻塞。
ArrayBlockingQueue
是一个用数组实现的有界阻塞队列。此队列按照先进先出（FIFO）的原则对元素进行排序。默认情况下不保证线程公平的访问队列，所谓公平访问队列是指阻塞的线程，可以按照阻塞的先后顺序访问队列，即先阻塞线程先访问队列。非公平性是对先等待的线程是非公平的，当队列可用时，阻塞的线程都可以争夺访问队列的资格，有可能先阻塞的线程最后才访问队列。初始化时有参数可以设置。
LinkedBlockingQueue
是一个用链表实现的有界阻塞队列。此队列的默认和最大长度为Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。
Array实现和Linked实现的区别
- 队列中锁的实现不同
ArrayBlockingQueue实现的队列中的锁是没有分离的，即生产和消费用的是同一个锁；
LinkedBlockingQueue实现的队列中的锁是分离的，即生产用的是putLock，消费是takeLock。 - 在生产或消费时操作不同
ArrayBlockingQueue实现的队列中在生产和消费的时候，是直接将枚举对象插入或移除的；LinkedBlockingQueue实现的队列中在生产和消费的时候，需要把枚举对象转换为Node进行插入或移除，会影响性能。 - 队列大小初始化方式不同
ArrayBlockingQueue实现的队列中必须指定队列的大小；
LinkedBlockingQueue实现的队列中可以不指定队列的大小，但是默认是Integer.MAX_VALUE。
PriorityBlockingQueue
PriorityBlockingQueue是一个支持优先级的无界阻塞队列。默认情况下元素采取自然顺序升序排列。也可以自定义类实现compareTo()方法来指定元素排序规则，或者初始化PriorityBlockingQueue时，指定构造参数Comparator来对元素进行排序。需要注意的是不能保证同优先级元素的顺序。
DelayQueue
是一个支持延时获取元素的无界阻塞队列。队列使用PriorityQueue来实现。队列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取当前元素。只有在延迟期满时才能从队列中提取元素。
DelayQueue非常有用，可以将DelayQueue运用在以下应用场景：
缓存系统的设计：可以用DelayQueue保存缓存元素的有效期，使用一个线程循环查询DelayQueue，一旦能从DelayQueue中获取元素时，表示缓存有效期到了。
SynchronousQueue
是一个不存储元素的阻塞队列。每一个put操作必须等待一个take操作，否则不能继续添加元素。SynchronousQueue可以看成是一个传球手，负责把生产者线程处理的数据直接传递给消费者线程。队列本身并不存储任何元素，非常适合传递性场景。
LinkedTransferQueue
多了tryTransfer和transfer方法，
（1）transfer方法
如果当前有消费者正在等待接收元素（消费者使用take()方法或带时间限制的poll()方法时），transfer方法可以把生产者传入的元素立刻transfer（传输）给消费者。如果没有消费者在等待接收元素，transfer方法会将元素存放在队列的tail节点，并等到该元素被消费者消费了才返回。
（2）tryTransfer方法
tryTransfer方法是用来试探生产者传入的元素是否能直接传给消费者。如果没有消费者等待接收元素，则返回false。和transfer方法的区别是tryTransfer方法无论消费者是否接收，方法立即返回，而transfer方法是必须等到消费者消费了才返回。
LinkedBlockingDeque
LinkedBlockingDeque是一个由链表结构组成的双向阻塞队列。所谓双向队列指的是可以从队列的两端插入和移出元素。双向队列因为多了一个操作队列的入口，在多线程同时入队时，也就减少了一半的竞争。
多了addFirst、addLast、offerFirst、offerLast、peekFirst和peekLast等方法，以First单词结尾的方法，表示插入、获取（peek）或移除双端队列的第一个元素。以Last单词结尾的方法，表示插入、获取或移除双端队列的最后一个元素。另外，插入方法add等同于addLast，移除方法remove等效于removeFirst。但是take方法却等同于takeFirst，不知道是不是JDK的bug，使用时还是用带有First和Last后缀的方法更清楚。在初始化
LinkedBlockingDeque时可以设置容量防止其过度膨胀。另外，双向阻塞队列可以运用在“工作窃取”模式中。
2 线程池
2.1 为什么要用线程池？
Java中的线程池是运用场景最多的并发框架，几乎所有需要异步或并发执行任务的程序都可以使用线程池。在开发过程中，合理地使用线程池能够带来3个好处。
第一：降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
第二：提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。假设一个服务器完成一项任务所需时间为：T1 创建线程时间，T2 在线程中执行任务的时间，T3 销毁线程时间。 如果：T1 + T3 远大于 T2，则可以采用线程池，以提高服务器性能。线程池技术正是关注如何缩短或调整T1,T3时间的技术，从而提高服务器程序性能的。它把T1，T3分别安排在服务器程序的启动和结束的时间段或者一些空闲的时间段，这样在服务器程序处理客户请求时，不会有T1，T3的开销了。
第三：提高线程的可管理性。线程是稀缺资源，如果无限制地创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一分配、调优和监控。
2.2 ThreadPoolExecutor的类关系
Executor是一个接口，它是Executor框架的基础，它将任务的提交与任务的执行分离开来。ExecutorService接口继承了Executor，在其上做了一些shutdown()、submit()的扩展，可以说是真正的线程池接口。AbstractExecutorService抽象类实现了ExecutorService接口中的大部分方法。ThreadPoolExecutor是线程池的核心实现类，用来执行被提交的任务。ScheduledExecutorService接口继承了ExecutorService接口，提供了带"周期执行"功能ExecutorService。ScheduledThreadPoolExecutor是一个实现类，可以在给定的延迟后运行命令，或者定期执行命令。ScheduledThreadPoolExecutor比Timer更灵活，功能更强大。
2.3 线程池创建各个参数的含义
public ThreadPoolExecutor(
int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
复制代码corePoolSize
线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程任务，直到当前线程数等于corePoolSize；
如果当前线程数为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行；
如果执行了线程池的prestartAllCoreThreads()方法，线程池会提前创建并启动所有核心线程。
maximumPoolSize
线程池中允许的最大线程数。如果当前阻塞队列满了，且继续提交任务，则创建新的线程执行任务，前提是当前线程数小于maximumPoolSize。
keepAliveTime
线程空闲时的存活时间，即当线程没有任务执行时，继续存活的时间。默认情况下，该参数只在线程数大于corePoolSize时才有用。
TimeUnit
keepAliveTime的时间单位。
workQueue
workQueue必须是BlockingQueue阻塞队列。当线程池中的线程数超过它的corePoolSize的时候，线程会进入阻塞队列进行阻塞等待。通过workQueue，线程池实现了阻塞功能。
一般来说，我们应该尽量使用有界队列，因为使用无界队列作为工作队列会对线程池带来如下影响。
1）当线程池中的线程数达到corePoolSize后，新任务将在无界队列中等待，因此线程池中的线程数不会超过corePoolSize。
2）由于1，使用无界队列时maximumPoolSize将是一个无效参数。
3）由于1和2，使用无界队列时keepAliveTime将是一个无效参数。
4）更重要的，使用无界queue可能会耗尽系统资源，有界队列则有助于防止资源耗尽，同时即使使用有界队列，也要尽量控制队列的大小在一个合适的范围。
threadFactory
创建线程的工厂，通过自定义的线程工厂可以给每个新建的线程设置一个具有识别度的线程名，当然还可以更加自由的对线程做更多的设置，比如设置所有的线程为守护线程。
Executors静态工厂里默认的threadFactory，线程的命名规则是“pool-数字-thread-数字”。
RejectedExecutionHandler
线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：
（1）AbortPolicy：直接抛出异常，默认策略；
（2）CallerRunsPolicy：用调用者所在的线程来执行任务；
（3）DiscardOldestPolicy：丢弃阻塞队列中靠最前的任务，并执行当前任务；
（4）DiscardPolicy：直接丢弃任务；
当然也可以根据应用场景实现RejectedExecutionHandler接口，自定义饱和策略，如记录日志或持久化存储不能处理的任务。
2.4 线程池的工作机制
1）如果当前运行的线程少于corePoolSize，则创建新线程来执行任务（注意，执行这一步骤需要获取全局锁）。
2）如果运行的线程等于或多于corePoolSize，则将任务加入BlockingQueue。
3）如果无法将任务加入BlockingQueue（队列已满），则创建新的线程来处理任务。
4）如果创建新线程将使当前运行的线程超出maximumPoolSize，任务将被拒绝，并调用RejectedExecutionHandler.rejectedExecution()方法。
2.5 提交任务
execute()方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功。
submit()方法用于提交需要返回值的任务。线程池会返回一个future类型的对象，通过这个future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用get（long timeout，TimeUnit unit）方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。
2.6 关闭线程池
可以通过调用线程池的shutdown或shutdownNow方法来关闭线程池。它们的原理是遍历线程池中的工作线程，然后逐个调用线程的interrupt方法来中断线程，所以无法响应中断的任务可能永远无法终止。但是它们存在一定的区别，shutdownNow首先将线程池的状态设置成STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表，而shutdown只是将线程池的状态设置成SHUTDOWN状态，然后中断所有没有正在执行任务的线程。
只要调用了这两个关闭方法中的任意一个，isShutdown方法就会返回true。当所有的任务都已关闭后，才表示线程池关闭成功，这时调用isTerminaed方法会返回true。至于应该调用哪一种方法来关闭线程池，应该由提交到线程池的任务特性决定，通常调用shutdown方法来关闭线程池，如果任务不一定要执行完，则可以调用shutdownNow方法。
2.7 合理的配置线程池
要想合理地配置线程池，就必须首先分析任务特性。
要想合理地配置线程池，就必须首先分析任务特性，可以从以下几个角度来分析：
- 任务的性质：CPU密集型任务、IO密集型任务和混合型任务。
- 任务的优先级：高、中和低。
- 任务的执行时间：长、中和短。
- 任务的依赖性：是否依赖其他系统资源，如数据库连接。
性质不同的任务可以用不同规模的线程池分开处理。
CPU密集型任务应配置尽可能小的线程，如配置Ncpu+1个线程的线程池。由于IO密集型任务线程并不是一直在执行任务，则应配置尽可能多的线程，如2*Ncpu。
混合型的任务，如果可以拆分，将其拆分成一个CPU密集型任务和一个IO密集型任务，只要这两个任务执行的时间相差不是太大，那么分解后执行的吞吐量将高于串行执行的吞吐量。如果这两个任务执行时间相差太大，则没必要进行分解。可以通过Runtime.getRuntime().availableProcessors()方法获得当前设备的CPU个数。
优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理。它可以让优先级高的任务先执行。
执行时间不同的任务可以交给不同规模的线程池来处理，或者可以使用优先级队列，让执行时间短的任务先执行。
建议使用有界队列。有界队列能增加系统的稳定性和预警能力，可以根据需要设大一点儿，比如几千。
如果当时我们设置成无界队列，那么线程池的队列就会越来越多，有可能会撑满内存，导致整个系统不可用，而不只是后台任务出现问题。
3 AbstractQueuedSynchronizer
3.1 学习AQS的必要性
队列同步器AbstractQueuedSynchronizer（以下简称同步器或AQS），是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作。并发包的大师（Doug Lea）期望它能够成为实现大部分同步需求的基础。
3.2 AQS使用方式和其中的设计模式
AQS的主要使用方式是继承，子类通过继承AQS并实现它的抽象方法来管理同步状态，在AQS里由一个int型的state来代表这个状态，在抽象方法的实现过程中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法（getState()、setState(int newState)和compareAndSetState(int expect,int update)）来进行操作，因为它们能够保证状态的改变是安全的。
/**
* The synchronization state.
*/
private volatile int state;
复制代码在实现上，子类推荐被定义为自定义同步组件的静态内部类，AQS自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用，同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型的同步组件（ReentrantLock、ReentrantReadWriteLock和CountDownLatch等）。
同步器是实现锁（也可以是任意同步组件）的关键，在锁的实现中聚合同步器。可以这样理解二者之间的关系：
锁是面向使用者的，它定义了使用者与锁交互的接口（比如可以允许两个线程并行访问），隐藏了实现细节；
同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁和同步器很好地隔离了使用者和实现者所需关注的领域。
实现者需要继承同步器并重写指定的方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些模板方法将会调用使用者重写的方法。
3.2.1 模板方法模式
同步器的设计基于模板方法模式。模板方法模式的意图是，定义一个操作中的算法的骨架，而将一些步骤的实现延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。我们最常见的就是Spring框架里的各种Template。
在Android，View的绘制onMeasure()、onLayout()、onDraw()三大流程也是用到了模板方法模式。
代码示例：
开了个蛋糕店，蛋糕店不能只卖一种蛋糕，于是我们决定先卖奶油蛋糕，芝士蛋糕等多种。这几种蛋糕在制作方式上一样，都包括造型，烘焙和涂抹蛋糕上的东西。所以可以定义一个抽象蛋糕模型蛋糕：
/**
* @Description: 抽象蛋糕模型
* @CreateDate: 2022/3/16 9:55 上午
*/
public abstract class AbstractCake {
/**
* 做造型
*/
protected abstract void shape();
/**
* 烤面包
*/
protected abstract void brake();
/**
* 涂抹
*/
protected abstract void apply();
/**
* 模板方法 做出一个完整的蛋糕
*/
public final void run() {
this.shape();
this.brake();
this.apply();
}
}
复制代码然后就可以批量生产几种蛋糕：
/**
* @Description: 芝士蛋糕
* @CreateDate: 2022/3/16 10:00 上午
*/
public class CheeseCake extends AbstractCake {
@Override
protected void shape() {
System.out.println("芝士蛋糕-做造型");
}
@Override
protected void brake() {
System.out.println("芝士蛋糕-烘烤");
}
@Override
protected void apply() {
System.out.println("芝士蛋糕-涂抹芝士");
}
}
复制代码/**
* @Description: 奶油蛋糕
* @CreateDate: 2022/3/16 10:02 上午
*/
public class CreamCake extends AbstractCake {
@Override
protected void shape() {
System.out.println("奶油蛋糕-做造型");
}
@Override
protected void brake() {
System.out.println("奶油蛋糕-烘烤");
}
@Override
protected void apply() {
System.out.println("奶油蛋糕-涂抹奶油");
}
}
复制代码/**
* @Description: 做蛋糕
* @CreateDate: 2022/3/16 10:04 上午
*/
public class MakeCake {
public static void main(String[] args) {
AbstractCake cake=new CheeseCake();
AbstractCake cake2=new CreamCake();
cake.run();
cake2.run();
}
}
复制代码这样一来，不但可以批量生产多种蛋糕，而且如果日后有扩展，只需要继承抽象蛋糕方法就可以了，十分方便。
3.2 AQS中的方法
3.2.1 模板方法
实现自定义同步组件时，将会调用同步器提供的模板方法。
这些模板方法同步器提供的模板方法基本上分为3类：独占式获取与释放同步状态、共享式获取与释放、同步状态和查询同步队列中的等待线程情况。
3.2.2 可重写的方法
3.2.3 访问或修改同步状态的方法
重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。
- getState()：获取当前同步状态。
- setState(int newState)：设置当前同步状态。
- compareAndSetState(int expect,int update)：使用CAS设置当前状态，该方法能够保证状态设置的原子性。
3.3 CLH队列
CLH队列锁即Craig, Landin, and Hagersten (CLH) locks。
CLH队列锁也是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程仅仅在本地变量上自旋，它不断轮询前驱的状态，假设发现前驱释放了锁就结束自旋。
当一个线程需要获取锁时：
1.创建一个的QNode，将其中的locked设置为true表示需要获取锁，myPred表示对其前驱结点的引用。
2.线程A对tail域调用getAndSet方法，使自己成为队列的尾部，同时获取一个指向其前驱结点的引用myPred。
线程B需要获得锁，同样的流程再来一遍。
3.线程就在前驱结点的locked字段上旋转，直到前驱结点释放锁(前驱节点的锁值 locked == false)。
4.当一个线程需要释放锁时，将当前结点的locked域设置为false，同时回收前驱结点。
如上图所示，前驱结点释放锁，线程A的myPred所指向的前驱结点的locked字段变为false，线程A就可以获取到锁。
CLH队列锁的优点是空间复杂度低（如果有n个线程，L个锁，每个线程每次只获取一个锁，那么需要的存储空间是O（L+n），n个线程有n个myNode，L个锁有L个tail）。CLH队列锁常用在SMP体系结构下。
Java中的AQS是CLH队列锁的一种变体实现。
3.4 ReentrantLock的实现
3.4.1 锁的可重入
重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞，该特性的实现需要解决以下两个问题。
1）线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。
2）锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。
nonfairTryAcquire方法增加了再次获取同步状态的处理逻辑：通过判断当前线程是否为获取锁的线程来决定获取操作是否成功，如果是获取锁的线程再次请求，则将同步状态值进行增加并返回true，表示获取同步状态成功。同步状态表示锁被一个线程重复获取的次数。
如果该锁被获取了n次，那么前(n-1)次tryRelease(int releases)方法必须返回false，而只有同步状态完全释放了，才能返回true。可以看到，该方法将同步状态是否为0作为最终释放的条件，当同步状态为0时，将占有线程设置为null，并返回true，表示释放成功。
3.4.2 公平和非公平锁
ReentrantLock的构造函数中，默认的无参构造函数将会把Sync对象创建为NonfairSync对象，这是一个“非公平锁”；而另一个构造函数ReentrantLock(boolean fair)传入参数为true时将会把Sync对象创建为“公平锁”FairSync。
La méthode nonfairTryAcquire (int acquiert), pour les verrous non équitables, tant que le CAS définit l'état de synchronisation avec succès, cela signifie que le thread actuel a acquis le verrou, alors que les verrous équitables sont différents. La méthode tryAcquire, par rapport à nonfairTryAcquire (int acquiert), la seule différence est que la condition de jugement a plus de méthode hasQueuedPredecessors (), c'est-à-dire, le jugement de savoir si le nœud actuel dans la file d'attente de synchronisation a un nœud prédécesseur est ajouté. renvoie vrai, cela signifie qu'un thread a demandé à acquérir le verrou plus tôt que le thread actuel, il est donc nécessaire d'attendre que le thread prédécesseur acquière et libère le verrou avant de continuer à acquérir le verrou.
Suivez la station Mushui (zhangmushui.cn) et le compte public WeChat [code Mushui] pour obtenir les dernières marchandises sèches techniques à temps.