Отвечая на мой собственный вопрос на тот случай, если кто-то еще подсунет об этом и сообщение на форумах Ehcache исчезнет.
Причина: Причина взаимоблокировки была в том же потоке, где была сделана попытка найти объект в кеше.В одной из нижних частей стека Ehcache делал readLock().lock() и writeLock().lock() для одного и того же объекта блокировки.Это, очевидно, нет-нет.
Почему это произошло? Это произошло из-за того, что кеш загружал другой объект как побочный эффект (еще одно большое нет-нет), и оба объекта заканчивались водин и тот же сегмент памяти (и, следовательно, разделяет один и тот же ReentrantLock).Подсказка: я использую ту же область кэша, поскольку не хочу указывать емкости для сотен различных типов объектов.
Почему это произошло? Произошла непреднамеренная загрузка при поиске ключа кэша из-замое отображение Hibernate.Объект (который ищется) имел составной ключ, ссылающийся на другой объект.Части этого составного ключа использовались в методе equals и вызывали эту нагрузку.По совпадению, загруженный объект также пытались поместить в тот же сегмент кэша, что привело к тупику.
Извлеченные уроки Будьте экстра осторожнее с вашими отображениями Hibernate.Если у вас есть составной ключ, никогда не используйте <key-many-to-one, так как это может привести к непредсказуемым результатам.Я думаю, что многие люди не осознают этого только потому, что они помещают разные типы объектов в разные области кэша, но непреднамеренные нагрузки, тем не менее, являются злыми.
Все кредиты отправляются Алексу с форумов Терракоты за помощь в выяснении этого.