TonyAlexer的博客

顾名思义，就是一种在对队列进行出队或者入队操作的时候会阻塞的队列。下面使用JDK17中的LinkedBlockingQuece进行简单的介绍。

ThreadLocal存储数据并不是直接存储数据，而是自己作为key将value存储到ThreadLocal自带的ThreadLocalMap中。ThreadLocalMap中负责存储键值对的数据结构为一维数组。这篇文章就来分析一下，ThreadLocalMap是如何进行hash取值，并如何解决碰撞问题。从下面代码可以看出键值对在数组中的位置由当前数组的大小len以及作为key的ThreadLocal对象的threadLocalHashCode来确定。

ThreadLocal 为线程提供一个线程安全的存储空间，只有该线程能够访问。实际上ThreadLocal其中并不存储数据，而是作为key，存储到Thread自带的ThreadLocal Map中。ThreadLocal的使用方法非常简单，在一个线程中声明出一个ThreadLocal变量便可以使用。下面的源码展示出ThreadLocal的基本使用ThreadLocal一共只暴露出了，五个public方法，我们首先研究一下这五个方法的作用。

下面分析一下，是如何实现折现线程安全的操作，首先需要用到Unsafe类，从名字就能看出来这是个 “不安全”的类，因为它提供了对底层内存的直接操作。如果操作时的值等于传入的expect值那么原子性更新为update的值，返回true；然后将对象实例，偏移量，以及expect值，和更新的值传入进到 Unsafe类提供的compareAndSetInt()中。Unsafe便会调用native方法去原子性更新STATE指向的内存的值。首先获取一个 Unsafe实例，然后获取类中字段的偏移量。

Java 监视器模式仅仅是一种编写代码的预定，对于任何一种锁对象，只要自始至终都是用该锁对象，都可以用来保护对象的状态。下面是一个私有锁保护状态的例子。在某些情况下，程序需要一种更复杂的同步策略，Java监视器模式的主要优势就在于它的简单性。私有锁优点：私有锁可以将锁封装起来，无法让客户代码得到锁，但是可以通过公有方法访问锁。如果需要验证某个共有访问的锁在程序中是否被正确执行，需要检查整个程序，而不是单个的类。遵循监视器模式的对象会把对象的所有可变状态封装起来，并由对象自己的内置锁来保护。

状态，表示该数据块被当前处理器缓存独占，那么针对这个数据块的写将不会产生让其他缓存失效的广播信号，而是直接将状态变为 M。当该数据块被其他缓存请求读的时候，表示数据块会被拷贝到另外的缓存，当前缓存中并非唯一拷贝了，状态则会转变为。发现MSI协议存在一个问题：在每次处理器想要读取读取一个数据块的时候，数据总会变成 Shared状态，即使没有其他的拷贝在其他处理器的缓存中。当该数据块被其他缓存请求写的时候，那么该数据块在被传输到其他拷贝后，该缓存的数据块失效，标记为 Shared。

发布（Publish）一个对象指，使得对象在当前作用域之外的代码中使用。当某个不该发布的对象被发布的时候被称为逸出（Escape）。比如将一个对象保存为static变量，让其他线程能够访问，或者通过一个public的方法去返回一个对象的引用。下面用static变量来举例。

假设当PROCESS获取锁之后，PROCESS2也来获取锁，那么就会使得LOCK指向新入队的PROCESS2节点，然后判断前继为PROCESS节点自己并不是第一个节点，那么开始自旋，自旋监控的是自身的locked字段。在MCS锁提出之前，普通的自旋锁忙等的时候是需要消耗cpu并且众多线程去访问同一个共享变量，这样做会导致缓存中的共享变量的拷贝频繁失效，也就是文中提到的大型内存多处理器中可扩展性和可接受性能的主要障碍。类似的，该锁分为三个部分，锁定义以及获取锁和释放锁两个操作。在这片论文中，作者们提到。

它是一种基于队列的自旋锁，线程通过自旋等待自己的前驱线程释放锁，从而实现了线程的有序访问。将节点的状态变为 GRANTED，通知下一个正在自旋节点等待的线程。两个操作，分配一个新的Request对象给L.tail并且把这个Request对象的状态变为GRANTED,表示新建出来的锁的状态是空闲的。CLH队列的讲解就此结束，可以看到论文中原始的CLH队列和AQS中使用的CLH变体队列还是有很大差异的。然后，定义了Process的结构，包含两个字段，分别为指向监视字段的watch，指向自己的 myreq。

null 的时候已经是false，直接进入part2。但是此时只是创建node，AQS会让线程再次自旋一次去尝试获取资源，因为我们的node没有入队，那么经过part1的时候失败再去part2，假设part2成功请求到了资源，那么结束执行，如果没有请求成功，那么经过一次自旋后，我们的线程依旧没有争取到资源，那么此时就要执行入队操作。如果解除阻塞后消耗尽了自旋次数还没有成功获取资源，那么就再次进入阻塞状态,同时会更新下次解除阻塞后允许的自旋次数，阻塞次数越多，允许自旋的次数越多，分别为1，3，7，15…

抽象队列同步器按照JDK17中的注释，主要目的是为开发者提供一个能够实现阻塞锁以及相关同步器的框架，这个框架依赖一个先进先出的等待队列。开发者为以及 JCP JSR-166的成员，经常阅读java.util.concurrent包源码的朋友对这个名字应该并不陌生。我们现在所熟知的JAVA并发开发工具类以及各种原子类都是由**Doug Lea以及JSR-166团队 **开发出的第一个版本，另外 **Doug Lea **也参与JSR-133 JAVA内存模型的改进工作。这些工作在JAVA1.5中正式发布。

可重入互斥独占锁（a reentrant mutual exclusion）默认创建的是非公平锁使用另一个构造函数能够指定公平锁和非公平锁从具体的实现上来看，公平锁与非公平锁同样是继承的一个Sync类，主要有两个方法不同。非公平锁使用CAS操作对AQS中的state进行compareAndSetState(0, 1)操作，具体AQS在干什么喝CAS操作是什么可以参考其他文章，比较复杂这里不在讲解。简单来说，在线程获取对象锁的时候，如果对象锁被其他对象获取，那么该线程就会进入一个同步队列进行排队。

想要读懂本文需要对计算机底层尤其是CPU主存以及缓存有一定的了解。本文目的在于帮助JAVA开发者了解多线程的底层究竟在发生什么，在多处理器计算机中是如何来处理程序的。

这是因为代码块加锁只锁住必要的部分，降低了锁的持有时间，从而减少了线程之间的等待和锁竞争。分别运行getV1() 和 getV2()的代码 5次，观察实验结果。只锁住了代码块，线程能够更快地获取到锁，执行效率更高。锁住了整个方法，导致线程在执行。时必须等待其他线程释放锁。

因为在第一次判断出instance为null的时候，可能有多个进程进入第一个判断为空的代码块。当在等待得到锁的线程需要再判断依次instance是否为空，因为可能已经有线程创建了instance。值得注意的是，重排序可能发生在编译在字节码阶段，jvm生成native code阶段，以及硬件执行阶段。这是因为两个线程可能同时进入这段代码，当判断instance为空的时候，都会去尝试新建一个实例。选择在方法块上加锁，值得注意的是这里出现了两次判断 instance是否为空因此该方法被命名为双重锁。

在学习JAVA多线程时，发现多线程内容是建立在JAVA内存模型上的。JAVA内存模型的上次主要更改在JAVA 5版本。

java同步代码块机制

竞态条件会使得结果变得不可靠。当某个计算的正确性取决于多个线程的交替执行时序时，就会发生竞态条件。最常见的竞态条件为，“先检查后执行（Check-Then-Act ）”即通过一个可能失效的观测结果决定下一步动作。

对于double以及long两种基本数据类型，所占位数为64位。而JVM却有32bit与64bit两种，也就是说在32bit JVM中不能将double 与 long类型的数据在一条指令中进行处理。为了处理64bit的数据，32bit的JVM会将一次对64bit的数据操作变为两次对32bit的操作。