太长别读——在我的应用程序中，许多线程在通过compute（）方法将条目插入到ConCurrentHashMap时，在READ模式下抓取ReentantReadWriteLock，并在传递给compute（）的lamdba完成后释放READ锁。有一个单独的线程在WRITE模式下抓取ReentantReadWriteLock并非常（非常）快速地释放它。当这一切发生时，并发HashMap正在调整大小（增长和收缩）。我遇到了一个挂起，我总是在堆栈跟踪中看到::的转移（），它在调整大小期间被调用。所有线程都被阻塞等待抓取MY ReentantReadWriteLock。复制器位于：https://github.com/rumpelstiltzkin/jdk_locking_bug

根据记录的行为，我做错了什么，还是这是一个JDK的bug？请注意，我不是在要求其他方法来实现我的应用程序。

详细信息：以下是关于为什么我的应用程序正在做它正在做的事情的一些上下文。再现器代码是一个简化版本来演示问题。

我的应用程序有一个直写缓存。条目被插入到缓存中，并带有插入时间的时间戳，单独的flusher-线程迭代缓存以查找在flusher-线程上次将条目持久化到磁盘之后创建的条目，即在last-flush-time之后。缓存只不过是一个并发HashMap。

现在，一个竞争是可能的，一个条目被构造成一个时间戳tX，当它被插入到并发HashMap中时，flusher-线程迭代缓存并且没有找到这个条目（它仍然被插入，所以在flusher-线程的Map::Iterator中还不可见），所以它不会持久化它，并且将last-flush-time颠簸到tY，使得tY

为了解决这个问题，使用新条目更新缓存的线程会在Lambda中以READ模式抓取一个ReentantReadWriteLock，该lambda::compute（）方法中构造缓存条目，并且flusher-线程在抓取其last-flush-time时以WRITE模式抓取相同的ReentantReadWriteLock。这确保了当flusher-线程抓取时间戳时，所有对象在Map中都是“可见的”，并且具有时间戳

在我的系统上复制：

$> java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

$> ./runtest.sh 
seed is 1571855560640
Main spawning 100 readers
Main spawned 100 readers
Main spawning a writer
Main spawned a writer
Main waiting for threads ... <== hung

所有线程（读取器和写入器）阻塞等待0x00000000c6511648

$> ps -ef | grep java | grep -v grep
user   54896  54895  0 18:32 pts/1    00:00:07 java -ea -cp target/*:target/lib/* com.hammerspace.jdk.locking.Main

$> jstack -l 54896 > jstack.1

$> grep -B3 'parking to wait for  <0x00000000c6511648>' jstack.1  | grep tid | head -10
"WRITER" #109 ...
"READER_99" ...
...

'top'显示我的java进程已经Hibernate了几分钟（它使用一点点的CPU增量来进行可能的上下文切换和不做的事情-请参阅top的手册页以了解为什么会发生这种情况）

$> top -p 54896
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                               
 54896 user      20   0 4630492 103988  12628 S   0.3  2.7   0:07.37 java -ea -cp target/*:target/lib/* com.hammerspace.jdk.locking.Main