AbstractQueuedSynchronizer预热的示例分析
这篇文章给大家分享的是有关AbstractQueuedSynchronizer预热的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
成都创新互联主营安庆网站建设的网络公司,主营网站建设方案,重庆APP开发公司,安庆h5微信平台小程序开发搭建,安庆网站营销推广欢迎安庆等地区企业咨询
核心方法预热
// 我不确定有多少人卡在这里
// 我是这么理解的 某个对象在jvm当中 是用一块数据来描述对象的所有信息
// 那么问题来了 如果我要设置某个对象的字段 通常的方法 对象引用.setXXXField(xxx)这个是通常的方法
// 还有一种比较特别的 unsafe提供的 unsafe.objectFieldOffset获取某个字段的偏移量 可以理解为存储信息的地址
// 获得了偏移地址之后 就可以使用 unsafe.compareAndSwapObject来原子的设置某个对象的字段
// 就是说 绕过通用的流程 直接修改相关数据了 顺带而且是原子性的
// 可以理解为玩游戏用外挂直接修改内存这种场景
headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head"));
unsafe.compareAndSwapObject(this, headOffset, expect, update);
tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
unsafe.compareAndSwapObject(this, tailOffset, expect, update);
/**
* 独占式获取同步状态，忽略线程的打断。
* 获取同步状态的逻辑是由重写的模板方法tryAcquire来实现的。
* 如果获取同步状态成功，则方法就直接返回。
* 否则，线程就会入队，一直会处于阻塞或者自旋，直到重复尝试tryAcquire成功。
* 该方法就是接口Lock#lock的实现。
* (从方法的介绍上面理解，就是说，这个接口直接的效果就是，获取同步成功，线程就从这个方法继续执行下去，如果不成功;
* 那么内部会经过一系列复杂的逻辑计算，直接体现就是线程不会继续执行下去，就一直处于这个方法内部。不执行下去的原因是：线程可能处于自旋或者阻塞。)
* @param arg 同步状态参数 透传进tryAcquire并且不响应终端或者其他情况(超时)
*
* 由两种判断逻辑
* 1. tryAcquire(arg) -> 返回
* 2. tryAcquire(arg) -> addWaiter(Node.EXECLUSIVE) -> acquireQueued(lastValue, arg) -> 返回并且可能会中断线程
*
* addWaiter(Node node) 入队
* acquireQueued(final Node node, int arg) 自旋或者阻塞
*
* 这个方法就是把整个流程已经写死了，必定会经过这么几个步骤。
* 唯一可以影响该方法中的流程，只能是模板方法tryAcquire，它的返回与否，导致流程的走向。
* 把自旋或者阻塞安排在if的条件语句中 会令人初步一看会感觉非常难受。(大神可以这么用，我们平时还是少用)。
*/
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
// 老老实实的我，一般会这么写 见笑见笑
public final void acquire(int arg) {
// 尝试获取同步状态
if (tryAcquire(arg)) {
return;
} else {
// 先入队 这里会有一个死循环
Node newNode = addWaiter(Node.EXCLUSIVE);
// 再自旋获取同步状态 或者阻塞 这里也会有死循环
boolean shouldCurrentThreadInterrupted = acquireQueued(newNode, arg);
// 再判断是否需要线程中断
if (shouldCurrentThreadInterrupted) {
selfInterrupt();
}
}
}
// 接下来看看这个模板方法的介绍
/**
* 尝试独占式获取同步状态。
* 该方法需要查询对象当前状态，判断同步状态是否符合预期。
* (我的理解就是，需要自己实现自己的逻辑，判断自己所要实现的逻辑是否符合自己的预期。记住是独占模式)
*
* 该方法经常再线程执行同步时被调用。
* 如果方法返回失败，那么线程就应该入队了，即使线程还没做好入队准备。
* (这里的意思就是说，线程在竞争锁之前，最好做好充足的准备工作，也就是前置逻辑要执行完，比如各种初始化判断。加锁之后就应该是确确实实的逻辑操作了，最好不要加完锁之后，又去判断各种前置业务逻辑操作。这个就是我理解的大师所要阐述的最佳实践。)
* 入队的线程只能等待别人释放之后唤醒。
* 一般前置方法就是为了实现Lock#tryLock这个。
*
* 默认实现式UnsupportedOperationException异常。
*
* @param arg 请求参数。
* 一般这个值是方法唯一的参数，或者保存于条件等待中。
* 所以不建议为这个值赋予更多其他含义。
* (我认为这里的意思是，这个值不要和业务中的某个条件或者流程挂钩，让值单纯的标识同步状态就好了。)
*
* @return true加锁成功。
* @throws IllegalMonitorStateException 如果获取同步时发现同步器处于一个不正确的状态时，
* 那么就必须抛出这个异常，目的时为了同步器逻辑正确。
* (我的理解，同步器状态很重要，必须严肃对待，因为一旦某个过程状态不正确，后续的业务逻辑可能会发生各种不可知的结果，并且，debug起来非常麻烦，因为业务逻辑可能正确，原因是同步状态的出错。这种是很隐晦的。也就是说，一旦碰到IllegalMonitorStateException，个人认为最好中断运行，排错。即使开发者认为这个错误不重要。你都已经自己实现锁的逻辑了，任何一点小的逻辑失误，都会造成不可预估的结果。千里之堤毁于蚁穴啊。)
* @throws UnsupportedOperationException 如果独占模式不支持抛异常
*/
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}
// 入队操作
/**
* 创建队列，并且把当前线程包装一下，指定某个节点模式，入队。
*
* @param mode Node.EXCLUSIVE 独占, Node.SHARED 共享
* @return 新的节点
*/
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// 先尝试直接队尾添加 如果不行在进行完整的入队操作 Try the fast path of enq; backup to full enq on failure
Node pred = tail;
// 队尾有两种情况
// 1 null 表示队列还没有初始化 初始化在enq(node)中
// 2 != null 表示队列初始化了 那么尝试快速添加队尾这个操作 我认为就是优化操作了
// (老老实实的我，一般并不会这么写，因为我比较稳妥。)
// (其实优化操作，理论上来说，可以不用的。)
// compareAndSetTail()这个原子性的操作 防止并发
// 并发操作的特点就是，随时随地都可能发生几个线程同时执行，所以，并发点，尽量条件简单点，如果业务条件够复杂，一定要拆，而且要分优先级的。不然，动态变化的条件加上锁，噩梦。
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
// 入队操作只需要建立一个尾链接就可以
pred.next = node;
return node; // 注意 这里返回的是新的节点
}
}
enq(node); // 这里方法返回的是节点前置的节点 但是没有使用 在唤醒流程中会复用这个方法
return node;
}
// 完整的入队流程逻辑
/**
* 入队操作，一定要先初始化队列。
* (死循环确保一定会入队成功，我对死循环的理解是，单线程不要用死循环，多线程可以适量的用，主线程不要用，非要用时情愿开个线程计算，等它计算结束再拿那个结果也可以。总结起来，能不用就不用，即使要用，千万别忘记了，自己在干什么。建议在自己精力最旺盛的时候，写带有死循环的逻辑。)
* @param node 入队节点
* @return 返回前置节点
*/
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // 队列初始化
// 原子性的设置头 这里注意这个head节点 这个head指向的node是一个空的node，里面没有node的关键数据的
if (compareAndSetHead(new Node()))
tail = head;
} else {
// 双向队列 尝试把当前节点的头设置为原本队尾那个 只要下面的cas队列设置好那就操作成功 不行再循环再来
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
/**
* 设置队列首节点 (因为是双向，队首的前驱是null，这个null是为了释放节点的。)
* 该方法仅仅只被同步器获取。
* null的目的是为了GC也为了不必要的信号释放遍历。
*
* @param node 设置队首
*/
private void setHead(Node node) {
head = node;
node.thread = null;
node.prev = null;
}
// 自旋
/**
* 独占不响应中断模式的线程获取同步方法。
* 条件等待也使用该方法。
*
* @param node 节点
* @param arg 获取同步参数
* @return true 如果等待时线程被打断
*/
final boolean acquireQueued(final Node node, int arg) {
// 获取同步状态是否失败
// 默认标记值是成功的
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
// 节点的前驱节点就是头节点
// 说明前面的节点，要么持有同步状态在进行业务逻辑操作，要么就已经释放锁了。这种情况下，获取同步器机会就很大。
// 再次尝试获取同步状态
if (p == head && tryAcquire(arg)) {
// 这里已经说明当前节点已经获得了同步状态 也就是说当前线程也获得执行业务逻辑的机会了
// 设置头节点很有技巧 设置完之后 头已经是一个虚拟的节点了
setHead(node);
p.next = null; // help GC
failed = false; // 这里其实个人认为是不需要设置了 除了习惯原因 我不知道还有什么特别的意思？因为返回的时候是表示线程是否被打断了标记
return interrupted;
}
// 获取失败判断线程是否需要阻塞
// 阻塞之后又要检查线程是否需要中断
//
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true; // 线程已经被打断
}
} finally {
if (failed)
cancelAcquire(node);
}
}
/**
* 当一个节点获取同状态失败时，检查并且更新它的状态。
* 返回true，那么线程需要被阻塞。
* 在所有的获取同步循环中，这个是最重要的信号控制。
* 前置条件是前置节点确切的是节点的前置节点。
*
* @param pred 带有状态的前驱节点
* @param node 节点
* @return true 线程被阻塞
*/
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* 前驱节点已经处于等待其他线程释放同步状态而将它唤醒。
* 那么当前节点应该能够安全的被阻塞。
*/
return true;
if (ws > 0) {
/*
* 前驱节点已经是取消状态。
* 跳过前驱节点在尝试。
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* 等待状态必须是0或者是传播状态(-3）。
* 仅需要一个信号，而并不需要阻塞。(应该是共享模式下的逻辑。)
* 调用者需要重新确保当前线程在阻塞之前是否需要获取同步状态。
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
/**
* 阻塞当前线程。恢复后检测线程是否被中断了。
*
* @return true} if interrupted
*/
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}感谢各位的阅读！关于“AbstractQueuedSynchronizer预热的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
分享标题：AbstractQueuedSynchronizer预热的示例分析
浏览路径：http://pwwzsj.com/article/gphcdg.html
