Deadlock in DefaultJdbiCache

[stevenschlansker]

Since upgrading to jdbi 3.37.0 with an internal cache, we experience a deadlock:

Thread 37 BLOCKED 'user-server-37': 
java.base@17.0.6/java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1122)
java.base@17.0.6/java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1102)
app//org.jdbi.v3.core.cache.internal.DefaultJdbiCache.expunge(DefaultJdbiCache.java:115)
app//org.jdbi.v3.core.cache.internal.DefaultJdbiCache.getWithLoader(DefaultJdbiCache.java:61)
app//org.jdbi.v3.core.statement.SqlStatements.preparedRender(SqlStatements.java:303)

Thread 53 BLOCKED 'user-server-53': 
app//org.jdbi.v3.core.cache.internal.DefaultJdbiCache.lambda$wrapLoader$1(DefaultJdbiCache.java:82)
app//org.jdbi.v3.core.cache.internal.DefaultJdbiCache$$Lambda$961/0x000000080134bf28.create(Unknown Source)
app//org.jdbi.v3.core.cache.internal.DefaultJdbiCache$$Lambda$1909/0x000000080165ca70.apply(Unknown Source)
java.base@17.0.6/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708)
app//org.jdbi.v3.core.cache.internal.DefaultJdbiCache.getWithLoader(DefaultJdbiCache.java:57)
app//org.jdbi.v3.core.statement.SqlStatements.preparedRender(SqlStatements.java:303)

Thread A holds expunge lock and calls in to CHM.remove, which takes a bucket lock.
Thread B holds the bucket lock and tries to take the expunge lock.

Looks like a classic lock order reversal.

[stevenschlansker]

cc @hgschmie