I would use the Initialization-on-demand holder idiom [1] instead, ex:
private static class SingletonHolder {
private static final Config singleton = new Config();
}
public static Config getInstance() throws KrbException {
return SingletonHolder.singleton;
}
This way you avoid
On 05/26/2015 09:45 AM, Weijun Wang wrote:
But here it's not a real singleton (not final), the refresh() method can
reassign an instance to it.
Oh. I missed that. Forget my suggestion then.
--Sean
--Max
On 5/26/2015 8:51 PM, Sean Mullan wrote:
I would use the Initialization-on-demand
synchronized on class looks a little bit unsafe to me. As singleton is
a static variable, creating the instance during initialization looks safer.
- private static Config singleton = null;
+ private static Config singleton = new Config();
Xuelei
On 5/25/2015 10:16 PM, 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]
As singleton is
a static variable, creating the instance during initialization looks safer.
- private static Config singleton =
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:
On 5/26/2015 9:22 AM, Xuelei Fan wrote:
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.
I do not like class level synchronization because it may not work as
expected, especially if the synchronization can be used by other codes.
However, your update does not change this behavior. The fix looks fine
to me. Please go ahead if you don't want to use object level
synchronization.
