On Tue, Jan 24, 2017 at 12:02 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
> a worker thread of the executor will try to execute the code of the static > method but because the static initializer is not finished, the worker > thread has to wait But what is the worker thread waiting for in the case of the lambda that it is not waiting for in the case of the AIC? I assume this is due to the lexical scoping of the lambda? As a rule of thumb, never starts a thread in a static block, you will get > this classical deadlock AND your code is hard to test because static blocks > tend to be executed in a random order (i.e. class loading is lazy so > execution of static blocks are lazy too). > This is the problem: I am a library author, and a user of my library ran into this problem. The user did not necessarily know that I was launching new threads in my library, and as a library author, I did not know I needed to advise users that they should not call my library from static blocks. It seems to be quite a big problem that a static block is not a standard execution context and can lead to deadlocks. Is there any way I can detect this in my code? I guess I could just get a stacktrace, and look for "<init>" or similar somewhere in the stacktrace, then throw an exception if called in this context? Is this a reliable enough test for being run in a static initializer block?
