Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

Luke Hutchison luke.hutch at gmail.com
Tue Jan 24 07:37:24 UTC 2017


On Mon, Jan 23, 2017 at 11:21 PM, Luke Hutchison <luke.hutch at gmail.com>
wrote:

> That looks like a variation of the classic class initialization deadlock
>> problem. Your main thread is blocked in es.submit(callable).get(); while
>> still within the static initializer of the LambdaBug class. If the executor
>> thread also needs to ensure LambdaBug is initialized (which it will in the
>> lambda case) then it will wait for the main thread to complete the
>> initialization. Hence deadlock.
>>
>
> Thanks for the explanation -- although I don't understand why a lambda
> expression requires its defining class to be initialized, whereas an
> anonymous inner class does not.
>

Also, I'm trying to determine if it is possible to detect cases like this
at runtime without triggering the deadlock, since I have already had one
bug report from a user of FastClasspathScanner running into this problem:

https://github.com/lukehutch/fast-classpath-scanner/issues/103


This user could not understand why FastClasspathScanner appeared to
deadlock when he passed in a lambda, but not when he passed in an anonymous
inner class.

Is it possible to examine an object to determine (1) if it was defined as a
lambda, and (2) if the enclosing class (i.e. the class that defined the
lambda) is initialized? (I can't see foolproof ways to do either of these
things, based on a cursory search.)  If so, at least I will be able to
throw an exception in my code, which will be better than hitting a deadlock
situation.


More information about the core-libs-dev mailing list