r*****l
发帖数: 2859 | 1 近来面试，发现不少人说不清楚singleton怎么实现。在这里说一下。知道的请跳过。
1, non-lazy |
r*****l
发帖数: 2859 | |
r*****l
发帖数: 2859 | |
g**e
发帖数: 6127 | 4 难道不是这种最好？
【在 r*****l 的大作中提到】
: 2, lazy #1
|
r*****l
发帖数: 2859 | 5 Both the 3 solutions should work. The non-lazy one is the simplest. Many
people give the solution with "synchronized" keyword but often did not get
it right.
【在 g**e 的大作中提到】
: 难道不是这种最好？
|
g*****g
发帖数: 34805 | 6 I think using the @Singleton annotation is the right approach.
And that should go into JSE |
r*****l
发帖数: 2859 | 7 Groovy supports that, right?
【在 g*****g 的大作中提到】
: I think using the @Singleton annotation is the right approach.
: And that should go into JSE
|
r***y
发帖数: 4379 | 8 hehe ...
sometimes, interviewers use this to distinguish between a newbie and a
guru.
this annotation will kill a group of interview questions
【在 g*****g 的大作中提到】
: I think using the @Singleton annotation is the right approach.
: And that should go into JSE
|
c*****t
发帖数: 1879 | 9 Annotation is such a powerful thing. Agree that singleton pattern
is simply not necessary, when the compiler could easily do it.
【在 g*****g 的大作中提到】
: I think using the @Singleton annotation is the right approach.
: And that should go into JSE
|
r***y
发帖数: 4379 | 10 aglee...
BTW, for your #3 , there are two trivial problems:
1) instance variable = null is unnecessary. interviewer is very picky :-)
2) volatile is a bit over-killed, because object reference is usually 32 bit
on 32 bit computer, 64 on 64 tit.
【在 r*****l 的大作中提到】
: Groovy supports that, right?
|
|
|
r*****l
发帖数: 2859 | 11 The keyword "volatile" is the key here. Without it, the implementation is
not correct.
It's not used to ensure locking, which is enforced with "synchronized". It's
used to ensure sequential consistency.
bit
【在 r***y 的大作中提到】
: aglee...
: BTW, for your #3 , there are two trivial problems:
: 1) instance variable = null is unnecessary. interviewer is very picky :-)
: 2) volatile is a bit over-killed, because object reference is usually 32 bit
: on 32 bit computer, 64 on 64 tit.
|
r***y
发帖数: 4379 | 12 you are right, otherwise, the point after "synchronized block" and before
"return instance" may generate 1+ objects.
that's a great point...
is
It's
【在 r*****l 的大作中提到】
: The keyword "volatile" is the key here. Without it, the implementation is
: not correct.
: It's not used to ensure locking, which is enforced with "synchronized". It's
: used to ensure sequential consistency.
:
: bit
|
r*****l
发帖数: 2859 | 13 This Wiki explains the situation:
http://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Ja
The more serious issue here is returning a partially constructed object.
【在 r***y 的大作中提到】
: you are right, otherwise, the point after "synchronized block" and before
: "return instance" may generate 1+ objects.
: that's a great point...
:
: is
: It's
|
g*****g
发帖数: 34805 | 14 The complexity is overrated. #3 is needed only if you are dealing
with multiple classloaders, and more than one loaders will access this
class, which is rarely the case in real world application.
【在 r*****l 的大作中提到】
: Both the 3 solutions should work. The non-lazy one is the simplest. Many
: people give the solution with "synchronized" keyword but often did not get
: it right.
|
r*****l
发帖数: 2859 | 15 I agree that the chance is quite small. However, bad thing may happen when
there is just one classloader.
"instance_ = new Singleton()"
may be executed in this way:
1, allocate a piece of memory and give the reference to instance_.
2, initialize Singleton object.
It's possible that after 1, and before 2, another thread comes in and get a
non null instance_ and use it.
【在 g*****g 的大作中提到】
: The complexity is overrated. #3 is needed only if you are dealing
: with multiple classloaders, and more than one loaders will access this
: class, which is rarely the case in real world application.
|
x*****p
发帖数: 1707 | |
F****n
发帖数: 3271 | 17 What's the difference between #1 and #2 since it is a Singleton class and it
will not be initialized until being loaded by a ClassLoader?
To make the point clear, you should use a user class rather than a dedicated
Singleton Class. |
S**********C
发帖数: 161 | 18 A follow-up question, can singleton be garbage collected?
if yes, how can it guarantee the variable is consistence
when it was reloaded.
if not, why it cannot be garbage collected? |
r*****l
发帖数: 2859 | 19 "you should use a user class rather than a dedicated Singleton Class"
Are you suggesting the way that Spring is working?
it
dedicated
【在 F****n 的大作中提到】
: What's the difference between #1 and #2 since it is a Singleton class and it
: will not be initialized until being loaded by a ClassLoader?
: To make the point clear, you should use a user class rather than a dedicated
: Singleton Class.
|
r*****l
发帖数: 2859 | 20 Once the class is loaded, the static variables are loaded and initialized.
They live while the class lives. Therefore, the references they hold live
while the class lives. Singleton instance is one of the references.
The single instance can only be GCed if there is no strong reference to it,
i.e. when the ClassLoader that loaded the singleton is GCed.
【在 S**********C 的大作中提到】
: A follow-up question, can singleton be garbage collected?
: if yes, how can it guarantee the variable is consistence
: when it was reloaded.
: if not, why it cannot be garbage collected?
|
|
|
S**********C
发帖数: 161 | 21 How to implement a per-thread-singleton?
You see, the question can be endless.
,
【在 r*****l 的大作中提到】
: Once the class is loaded, the static variables are loaded and initialized.
: They live while the class lives. Therefore, the references they hold live
: while the class lives. Singleton instance is one of the references.
: The single instance can only be GCed if there is no strong reference to it,
: i.e. when the ClassLoader that loaded the singleton is GCed.
|
F****n
发帖数: 3271 | 22 Factory with shared instances
Factory.getInstance(Object requestObject);
where requestObject can be stored by Factory
in a WeakReference map.
【在 S**********C 的大作中提到】
: How to implement a per-thread-singleton?
: You see, the question can be endless.
:
: ,
|
g*****g
发帖数: 34805 | 23 Use ThreadLocal
【在 S**********C 的大作中提到】
: How to implement a per-thread-singleton?
: You see, the question can be endless.
:
: ,
|
t**r
发帖数: 3428 | 24
lazy的解法比non-lazy的有什么好处和坏处？
【在 r*****l 的大作中提到】
: 近来面试，发现不少人说不清楚singleton怎么实现。在这里说一下。知道的请跳过。
: 1, non-lazy
|
r*****l
发帖数: 2859 | 25 Bingo!
【在 g*****g 的大作中提到】
: Use ThreadLocal
|
S**********C
发帖数: 161 | 26 Yeah, ThreadLocal is the right answer, and talking about ThreadLocal, there
is a interview questions I met before: "How do you implement the ThreadLocal
class if there is no such class in JDK"....
I was like....huh...ahh.
【在 r*****l 的大作中提到】
: Bingo!
|
g**e
发帖数: 6127 | 27 there are similar questions like implement your own reentrant lock, your own
hashmap etc.
not very picky questions if the position is for senior 码工
there
ThreadLocal
【在 S**********C 的大作中提到】
: Yeah, ThreadLocal is the right answer, and talking about ThreadLocal, there
: is a interview questions I met before: "How do you implement the ThreadLocal
: class if there is no such class in JDK"....
: I was like....huh...ahh.
|
r*****l
发帖数: 2859 | 28 Lazy approach will hold the initialization till the last possible moment.
This reduces the application startup time, and may avoid the initiation all
together. On the other hand, it may not reveal possible failure at the
beginning.
If the constructor throws exception, you probably have to use lazy #2.
是好处，或者坏处就见仁见智了。
【在 t**r 的大作中提到】
:
: lazy的解法比non-lazy的有什么好处和坏处？
|
g**e
发帖数: 6127 | 29 这几天翻effective java, josh bloch推荐了一个enum singleton的写法，他提到
"it is more concise, provides the serialization machinery for free, and
provides an
ironclad guarantee against multiple instantiation, even in the face of
sophisticated
serialization or reflection attacks. While this approach has yet to be
widely
adopted, a single-element enum type is the best way to implement a
singleton."
但是这个不是lazy的
public final class SingletonEnum {
public enum enumSingleton {
INSTANCE;
private int num = 0;
public String get() {
return "this is a enum singleton";
}
public int getNum() {
return this.num;
}
public void setNum(int w) {
this.num = w;
}
}
}
all
【在 r*****l 的大作中提到】
: Lazy approach will hold the initialization till the last possible moment.
: This reduces the application startup time, and may avoid the initiation all
: together. On the other hand, it may not reveal possible failure at the
: beginning.
: If the constructor throws exception, you probably have to use lazy #2.
: 是好处，或者坏处就见仁见智了。
|
r*****l
发帖数: 2859 | 30 I also saw this. While I felt it a rather weird way.
【在 g**e 的大作中提到】
: 这几天翻effective java, josh bloch推荐了一个enum singleton的写法，他提到
: "it is more concise, provides the serialization machinery for free, and
: provides an
: ironclad guarantee against multiple instantiation, even in the face of
: sophisticated
: serialization or reflection attacks. While this approach has yet to be
: widely
: adopted, a single-element enum type is the best way to implement a
: singleton."
: 但是这个不是lazy的
|
