From forum thread http://forums.terracotta.org/forums/posts/list/1107.page

synchronization in StandardDSOClientConfigHelperImpl.getInstrumentationDescriptorFor() method can lead to deadlocks, because the call to InstrumentationDescriptor.matches(..) within the synchronized block triggers many more method calls which can contend for locks. In the case of this forum post, the other lock belonged to a ClassLoader instance that was already held by another thread, which was trying to acquire the lock for the LinkedList of InstrumentationDescriptors.

It would be nice to go to a copy-on-write data structure to hold those InstrumentationDescriptors, so synchronization wasn't necessary on the read operations. If nothing else, you could always copy-on-read within the synchronized block, then iterate and check after relinquishing the lock. Tim points out that there may be additional more complicated synchronization and atomicity requirements around the addIncludeAndLockIfRequired() method (but we could use a different lock there).