Box Cat Happy Day
本系列是基于经验设计原型，然后不断优化最终达到和AQS（AbstractQueuedSynchronizer）类似的设计。最终结果不一定和AQS完全一致，基于个人理解会有修改，可以作为理解AQS的不完全参考。
接上篇。本篇主要介绍Condition即条件变量的实现，ReentrantLock中最后一块需要实现的内容。
在实现条件变量之前，考虑一下条件变量的一些特性。
注意第一条特性，条件变量依赖的是独占锁，所以类似读锁这种共享锁是不支持条件变量的，ReentrantReadWriteLock中ReadLock#newCondition的实现是直接抛错。
按照第二条特性，可以得到如下的执行过程
Continue reading “Java并发研究 自己写ReentrantLock和ReentrantReadWriteLock（3）”
接着上篇，本篇主要介绍如何添加限时tryLock方法。介绍完之后，ReentrantLock除了condition之外都会实现，而且基本和实际ReentrantLock代码接近。上篇也提到过，实际ReentrantLock依赖AQS，但是本文不会直接介绍AQS，只是AQS的一个不完全分析。
顺便提一下，“自己写ReentrantLock和ReentrantReadWriteLock”由于篇幅比较长，预计会分成3到4篇左右。
在进入限时tryLock方法的介绍之前，考虑一个问题：上篇中FairLock1和UnfairLock1是否可以复用Node？
为什么要问这个问题？因为C++代码比较关注对象的生命周期。使用C++实现锁的话必须关注何时可以回收Node的内存。如果你了解CLHLock的话，可以知道CLHLock是可以复用Node的，最多是N个（线程）+1个（哨兵）Node，理论上不需要回收。所以和CLHLock基本一致的FairLock1，同样可以用类似CLHLock的方式，即复用前序节点为自己的当前节点（CLHLock是复用前序节点的，至于为什么可以参阅CLHLock的介绍）。UnfairLock1中由于可能是非公平模式，不知道前序节点是谁，也就无法简单复用了。
Continue reading “Java并发研究 自己写ReentrantLock和ReentrantReadWriteLock（2）”
最近个人在研究如何实现Transaction Memory，这其实也是受《the art of multiprocessor programming》最后一章的影响。作为研究的一部分，个人需要一个类似ReadWriteLock语义的同步器，于是分析了一下现有ReentrantLock和ReentrantReadWriteLock。在分析之前我其实知道ReentrantLock和ReentrantReadWriteLock都是基于AbstractQueuedSynchronizer，所以本篇也可以作为AbstractQueuedSynchronizer的不完全分析。
首先从ReentrantLock开始分析。最简单的不公平模式，无等待（SPIN，PARK）的锁。
Continue reading “Java并发研究 自己写ReentrantLock和ReentrantReadWriteLock（1）”
如果没记错的话，这次是自己第一次写年度小结。为什么突然想写小结？可能主要是因为自己觉得在2018年里技术有比较大的进步吧。
2018年上半年抱着自己实现一个MQ的想法，空闲时间收集相关资料，学习Netty，每天看看《开发者头条》。
2018年中期，Netty学得差不多了，决定在实现MQ之前，找一个东西练手，结果把Raft实现了一遍。虽然不够完美，但是第一次接触了分布式领域的论文。之后又阅读了GOSSIP相关论文，基于自己的理解，实现了基于GOSSIP的集群管理（动态加入和退出）。
如果对上述代码有兴趣，欢迎到github上阅读和关注。
https://github.com/xnnyygn/xraft
https://github.com/xnnyygn/xgossip
代码开发中，觉得自己的并发编程技术有所欠缺，在寻找并发编程资料时，发现了《the art of multiprocessor programming》。这本书绝对是我从学编程开始找到的最好的一本书。开始看了之后就一发不可收拾，花了几个月看完第一遍之后，现在看第二遍中。最近每周一篇的Java并发库的分析，之后有机会的话准备写一本《如何自己写并发库》相关的书。