coroutine waiting for lock on a thread，cpu 100%

[eshenzw]

"coroutine-container-thread--3" #198 prio=5 os_prio=0 tid=0x00007f411d387800 nid=0x82b runnable [0x00007f41158f1000]
java.lang.Thread.State: RUNNABLE
at com.github.benmanes.caffeine.cache.BaseMpscLinkedArrayQueue.offer(MpscGrowableArrayQueue.java:280)

• parking to wait for <0x0000000761fe01f0> (a java.util.concurrent.CountDownLatch$Sync)
  at com.github.benmanes.caffeine.cache.BoundedLocalCache.afterWrite(BoundedLocalCache.java:1355)
  at com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2411)
  at com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2327)
  at com.github.benmanes.caffeine.cache.LocalAsyncCache.get(LocalAsyncCache.java:91)
  at com.github.benmanes.caffeine.cache.LocalAsyncCache.get(LocalAsyncCache.java:82)
  --
  at com.alibaba.wisp.engine.WispEngine$CacheableCoroutine.run(WispEngine.java:1042)
  at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)

• Coroutine [0x7f41187e7d40] "coroutine-container-thread--3" LoadingCache::get returns value after invoking RemovalListener #177
  at java.dyn.CoroutineSupport.symmetricYieldTo(CoroutineSupport.java:157)

• parking to wait for <0x0000000761fe01f0> (a java.util.concurrent.CountDownLatch$Sync)
  at java.dyn.Coroutine.yieldTo(Coroutine.java:110)

[ben-manes]

Hi,

You will need to discuss that with the Alibaba team, as that is a non-standard JDK which we do not support. The MpscGrowableArrayQueue from JCTools is lock-free and our code does not use CountDownLatch, so I do not know why they would have inserted that construct in. When offering fails to add into MpscGrowableArrayQueue, we do not spin forever and instead fall by acquiring a ReentrantLock. That avoids busy wait livelock issues that would cause high cpu, and allow other threads to catch up and drain this queue. Therefore, the problem does not appear to be in Caffeine and something internal to the WispEngine.

Sorry I can't be of more help.