Try to fix the synchronisation of the language detection singleton in…

[lfoppiano]

…itialisation in case of multithread environment.

There are many different theories around this, but basically what I understood is that

• double null check + synchronize + volatile correctly works, so thread are locked after null checking the instance... but a secondary check avoid threads that have passed the null check to repeat the initialisation.
• not sure it's faster than just synchronize the method every time

[coveralls]

Coverage increased (+0.003%) to 38.275% when pulling e888436 on bugfix/synchronisation-language-detection into d6ac4df on master.

[de-code]

But whether it is worth the time saving over just synchronized I don't know. How often will it be called?

Looks to be the correct way of implementing double checked locking.

There are actually alternatives that you could consider as well:
Initialization on-demand holder (using the classloader)

I was previously in favour of using AtomicReference but it would just wrap the volatile. I am surprised that Java still doesn't seem to offer a simple lazy initialization wrapper where you can pass in a callable (like ThreadLocal).

Apache commons has LazyInitializer. Maybe that would be more readable.

[kermitt2]

Thank you Luca, it looks all good and solved the problem when testing with the grobid python client. Thank you @de-code for the pointers!
So, good to learn, lazyness requires more work :D