Ребят, кто-нибудь сталкивался с таким? Есть 16 потоков, которые делят один

Question

Ребят, кто-нибудь сталкивался с таким? Есть 16 потоков, которые делят один

ReentrantReadWriteLock (fair = true). Они его используют подавляющее количество времени на чтение. Иногда включается запись. Время под локами короткое (меньше миллисекунды).

В основном все работает хорошо, но иногда получение read локов начинает "застревать", иногда на секунду и более. Если снять хип дамп (или тред дамп) в это время, то все потоки будут в TIMED_WAITING и вот таким стек трейсом (самый верх):
"thread-name" daemon prio=5 tid=72 TIMED_WAITING
at jdk.internal.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1079)
local variable: java.util.concurrent.locks.AbstractQueuedSynchronizer$Node#778
at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1369)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:882)

Т.е. все 16 потоков не могут взять пустой (специально проверил в хип дампе) лок на чтение.

Профайлинг (itimer режим из async-profiler) во время затупа показывает, что также до 35% времени CPU проводит в этих методах.

Застревают не намертво, какой-то проргесс идет. Потоки обрабатывают некие запросы, throughput во время затупа падает раз в 10, но не до 0.
Происходит это с завидной регулярностью на 9 машинах. Проходит само, но может занять час и более, ну и решается рестартом процесса.
Fedora 33, OpenJDK 11.

Есть идеи, куда копать?