On 5/26/2015 9:06 AM, Weijun Wang wrote: > On 5/26/2015 7:59 AM, Xuelei Fan wrote: >> synchronized on class looks a little bit unsafe to me. > > Why? Isn't it the same as making a static method synchronized? [1] > Other code may be also able to lock on class.
Code 1: lock on MyClass.class Code 2: lock on MyClass.class Code 1 and 2 know nothing about each other. The behavior may be weird. I don't think it is a good practice. >> As singleton is >> a static variable, creating the instance during initialization looks >> safer. >> >> - private static Config singleton = null; >> + private static Config singleton = new Config(); > > This line might throw an exception. Also, do you intend to make > getInstance() simply returning singleton? This means if the first call > to new Config() throws an exception, getInstance() will not try to > reconstruct it. This might not be common in production, but I don't want > to make any behavior change. > I see you point. Maybe, you can lock on a object. Xuelei > --Max > > [1] > https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 > >> >> Xuelei >> >> On 5/25/2015 10:16 PM, Weijun Wang wrote: >>> Hi All >>> >>> Please review a code change at >>> >>> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >>> >>> I've limit the synchronized block to Config creation only and therefore >>> won't deadlock with EType's class initialization. >>> >>> Noreg-hard. The EType call is at class initialization and only run once >>> in a VM session, which is extremely difficult to catch. >>> >>> Thanks >>> Max >>
