Use volatile referneces to prevent double creation of Ryuk containers - #2929

Ah, this would make sense. I wonder if @bsideup's #2882, which is also touching DockerClientFactory, will solve this. I think Lombok's lazy Getter should take care of race conditions on the dockerClient field by wrapping it in an atomic reference, so perhaps this problem goes away?

Since we synchronize our access to the fields, volatile should be unnecessary:
https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#myth-sync-vs-volatiles

@aguibert do you think you can provide a reproducer (e.g. by starting multiple threads and triggering the resolve)?

I can't easily create a reproducer for this -- it happens pretty intermittently.

Thanks for pointing out the article, I did a bit more research on volatile vs. synchronized and realized that synchrnozed also synchronizes the thread memory and main memory for all variables, in addition to locking. Given that, I'll go ahead and close this PR as it will not fix the problem I was trying to solve

@aguibert I will try to run it with JCStress then. Thanks for confirming that it is happening on your environment! At least we will be able to verify whether the fix worked or not :)

yw, and thanks for being so helpful as always @bsideup! Just to confirm I've got this right, do you think that #2930 will fix the issue? If so I will watch for that release and upgrade my env to use it

@aguibert I am afraid it won't fix the double Ryuk issue, but I am currently trying to reproduce it, so that we can finally fix the problem (although without any luck so far :( )