g**e
发帖数: 6127 | 1 Write a special singleton class, the class has one integer field, make sure
only one instance of this class will be instantiated for the same value of
the integer field.
jobhunting版有人给了个代码，我改了一下，高手看看对不对，谢谢. 用了double
lock checking
public class SpecialSingleton {
private final int i;
private volatile static SpecialSingleton instance = null;
private static ConcurrentHashMap
instanceMap = new ConcurrentHashMap();
|
J*******n
发帖数: 2901 | 2 学习了
sure
【在 g**e 的大作中提到】
: Write a special singleton class, the class has one integer field, make sure
: only one instance of this class will be instantiated for the same value of
: the integer field.
: jobhunting版有人给了个代码，我改了一下，高手看看对不对，谢谢. 用了double
: lock checking
: public class SpecialSingleton {
: private final int i;
: private volatile static SpecialSingleton instance = null;
: private static ConcurrentHashMap
: instanceMap = new ConcurrentHashMap();
|
g*****g
发帖数: 34805 | 3 This is correct, but not neccesarily the most efficient.
I would do it this way. And if create SpecialSinglton is
a heavy function, you can consider using Future. Check
the memoizer pattern.
instance = instanceMap.get(i);
if (instance == null) {
instance = new SpecialSingleton(i);
temp = instanceMap.putIfAbsent(i, instance);
if(temp != null) return temp;
}
return instance;
【在 g**e 的大作中提到】
: Write a special singleton class, the class has one integer field, make sure
: only one instance of this class will be instantiated for the same value of
: the integer field.
: jobhunting版有人给了个代码，我改了一下，高手看看对不对，谢谢. 用了double
: lock checking
: public class SpecialSingleton {
: private final int i;
: private volatile static SpecialSingleton instance = null;
: private static ConcurrentHashMap
: instanceMap = new ConcurrentHashMap();
|
g**e
发帖数: 6127 | 4 谢谢好虫，忘记这个pubIfAbsent了...
有个问题，temp = instanceMap.putIfAbsent(i, instance)，如果添加新元素，返回
的应该是null吧，这时候再返回instance，依然是null？
of
;
【在 g*****g 的大作中提到】
: This is correct, but not neccesarily the most efficient.
: I would do it this way. And if create SpecialSinglton is
: a heavy function, you can consider using Future. Check
: the memoizer pattern.
: instance = instanceMap.get(i);
: if (instance == null) {
: instance = new SpecialSingleton(i);
: temp = instanceMap.putIfAbsent(i, instance);
: if(temp != null) return temp;
: }
|
g*****g
发帖数: 34805 | 5 如果返回null，那就是你创建的放进去了，当然返回instance，
否则你的就没放进去，返回的是map里面的，所以返回temp.
【在 g**e 的大作中提到】
: 谢谢好虫，忘记这个pubIfAbsent了...
: 有个问题，temp = instanceMap.putIfAbsent(i, instance)，如果添加新元素，返回
: 的应该是null吧，这时候再返回instance，依然是null？
:
: of
: ;
|
g**e
发帖数: 6127 | 6 啊，对，我没看清楚，前面instance已经创建好了。呵呵不好意思。谢谢
【在 g*****g 的大作中提到】
: 如果返回null，那就是你创建的放进去了，当然返回instance，
: 否则你的就没放进去，返回的是map里面的，所以返回temp.
|
m******t
发帖数: 2416 | 7 Will somebody please enlighten me how this code isn't broken in this
situation:
1. Thread A executes the instance assignment in the if block, and gets
scheduled away,
2. Thread B comes in, executes the first instance assignment in the method
with a different i, and gets scheduled away,
3. Thread A comes back and... puts the instance retrieved by B into the map
under its own i?
I don't think volatile gets you _that_ far, and if you are going to tell me
B can't call get because A still has the loc |
g**e
发帖数: 6127 | 8 你说的是好虫的还是我的，我写的那个锁了instanceMap，没这个问题吧。但是我想了
一下，头两行可能就有问题
instance = instanceMap.get(i);
if (instance == null) {
有可能Thread A取i, Thread B取j，假设A先进去创建了instance，这时候B才检查
instance == null，会直接返回A创建的instance吧。
解决的办法是不是加一个判断?
if (instance == null || instance.getI() != i) {
...
}
map
me
【在 m******t 的大作中提到】
: Will somebody please enlighten me how this code isn't broken in this
: situation:
: 1. Thread A executes the instance assignment in the if block, and gets
: scheduled away,
: 2. Thread B comes in, executes the first instance assignment in the method
: with a different i, and gets scheduled away,
: 3. Thread A comes back and... puts the instance retrieved by B into the map
: under its own i?
: I don't think volatile gets you _that_ far, and if you are going to tell me
: B can't call get because A still has the loc
|
s******n
发帖数: 876 | 9 static public class SpecialSingleton
{
private static Map instanceMap
= new HashMap();
private final int i;
private SpecialSingleton(int i)
{
this.i = i;
}
synchronized public static SpecialSingleton getInstance(int i)
{
SpecialSingleton instance = instanceMap.get(i);
if (instance == null)
instanceMap.put(i, instance |
g**e
发帖数: 6127 | 10 这样写当然没问题，面试的人要求high performance
【在 s******n 的大作中提到】
: static public class SpecialSingleton
: {
: private static Map instanceMap
: = new HashMap();
: private final int i;
: private SpecialSingleton(int i)
: {
: this.i = i;
: }
: synchronized public static SpecialSingleton getInstance(int i)
|
|
|
g**e
发帖数: 6127 | 11 加判断也不行呀，有可能在return之前instance就被改变了...
method
ConcurrentHashMap
【在 g**e 的大作中提到】
: 你说的是好虫的还是我的，我写的那个锁了instanceMap，没这个问题吧。但是我想了
: 一下，头两行可能就有问题
: instance = instanceMap.get(i);
: if (instance == null) {
: 有可能Thread A取i, Thread B取j，假设A先进去创建了instance，这时候B才检查
: instance == null，会直接返回A创建的instance吧。
: 解决的办法是不是加一个判断?
: if (instance == null || instance.getI() != i) {
: ...
: }
|
m******t
发帖数: 2416 | 12 I was talking about the original code you posted. The race condition that I
think
exists is about instance. Synchronizing on instanceMap wouldn't help.
【在 g**e 的大作中提到】
: 你说的是好虫的还是我的，我写的那个锁了instanceMap，没这个问题吧。但是我想了
: 一下，头两行可能就有问题
: instance = instanceMap.get(i);
: if (instance == null) {
: 有可能Thread A取i, Thread B取j，假设A先进去创建了instance，这时候B才检查
: instance == null，会直接返回A创建的instance吧。
: 解决的办法是不是加一个判断?
: if (instance == null || instance.getI() != i) {
: ...
: }
|
m******t
发帖数: 2416 | 13 Yes, there is a race condition here as well. I like shuiguan's version
better -
nothing fancy but easy to verify.
【在 g**e 的大作中提到】
: 你说的是好虫的还是我的，我写的那个锁了instanceMap，没这个问题吧。但是我想了
: 一下，头两行可能就有问题
: instance = instanceMap.get(i);
: if (instance == null) {
: 有可能Thread A取i, Thread B取j，假设A先进去创建了instance，这时候B才检查
: instance == null，会直接返回A创建的instance吧。
: 解决的办法是不是加一个判断?
: if (instance == null || instance.getI() != i) {
: ...
: }
|
g**e
发帖数: 6127 | 14 明白了，这个instance在好几个地方都有可能改变，第一个if那里，put那里，还有最
后return之前
大牛你有没有不用synchronized getInstance的方法？
I
【在 m******t 的大作中提到】
: I was talking about the original code you posted. The race condition that I
: think
: exists is about instance. Synchronizing on instanceMap wouldn't help.
|
g**e
发帖数: 6127 | 15 这个据说是google的面试题，面试的哥们给了shiguan的方法，但是人家要高性能的
【在 m******t 的大作中提到】
: Yes, there is a race condition here as well. I like shuiguan's version
: better -
: nothing fancy but easy to verify.
|
m******t
发帖数: 2416 | 16
I'm honestly too old for this sh*t. :) Not worth killing brain cells
_and_ the embarrassment if whatever clever scheme I come up
with turns out wrong.
【在 g**e 的大作中提到】
: 明白了，这个instance在好几个地方都有可能改变，第一个if那里，put那里，还有最
: 后return之前
: 大牛你有没有不用synchronized getInstance的方法？
:
: I
|
g**e
发帖数: 6127 | 17 哈哈，你说的对
【在 m******t 的大作中提到】
:
: I'm honestly too old for this sh*t. :) Not worth killing brain cells
: _and_ the embarrassment if whatever clever scheme I come up
: with turns out wrong.
|
g*****g
发帖数: 34805 | 18 You are right, but the instance variable itself
is totally unnecessary. Using a local variable there
the code should be fine.
map
me
【在 m******t 的大作中提到】
: Will somebody please enlighten me how this code isn't broken in this
: situation:
: 1. Thread A executes the instance assignment in the if block, and gets
: scheduled away,
: 2. Thread B comes in, executes the first instance assignment in the method
: with a different i, and gets scheduled away,
: 3. Thread A comes back and... puts the instance retrieved by B into the map
: under its own i?
: I don't think volatile gets you _that_ far, and if you are going to tell me
: B can't call get because A still has the loc
|
m******t
发帖数: 2416 | 19
I could be wrong but I don't think local variables can be volatile, which
would make
the double check locking part seem a little shaky...
【在 g*****g 的大作中提到】
: You are right, but the instance variable itself
: is totally unnecessary. Using a local variable there
: the code should be fine.
:
: map
: me
|
g*****g
发帖数: 34805 | 20 I could be wrong but I think it will work.
The reason double check locking has potential issue was due to the
fact that initialization and assignment is not necessarily in the
right order. So if you invoke the get functions on the object for
example, you can see the default 0, null and false there instead
of the right initialized values.
However, with a map, you explicitly initialize first, then
assign second (by putting it into the map). So when you are in
the sync block, the entry is either cr
【在 m******t 的大作中提到】
:
: I could be wrong but I don't think local variables can be volatile, which
: would make
: the double check locking part seem a little shaky...
|
|
|
g**e
发帖数: 6127 | 21 这样？
if (instanceMap.get(i) == null) {
synchronized (instanceMap){
if (instanceMap.get(i) == null) {
instanceMap.put(i, new
SpecialSingleton(i));
}
}
}
return instanceMap.get(i);
或者您老写的这样？
if (instanceMap.get(i) == null) {
instanceMap.putIfAbsent(i, new Specia
【在 g*****g 的大作中提到】
: I could be wrong but I think it will work.
: The reason double check locking has potential issue was due to the
: fact that initialization and assignment is not necessarily in the
: right order. So if you invoke the get functions on the object for
: example, you can see the default 0, null and false there instead
: of the right initialized values.
: However, with a map, you explicitly initialize first, then
: assign second (by putting it into the map). So when you are in
: the sync block, the entry is either cr
|
m***h
发帖数: 77 | 22 have you considered
public enum MySingleton{
INSTANCE;
....
}
Must be JDK 1.5 or above.
Not sure how the instance-map is handled here. |
c*****t
发帖数: 1879 | 23 Two issues.
1. As magicfat has pointed out, you have a race condition. Normally,
you need to check-and-check-again to verify the value. That is:
instance = map.get (i);
if (instance == null)
{
synchronized (...)
{
instance = map.get (i); // very important!
if (instance == null)
{
// instantiation
}
}
}
2. Note that, synchronized map itself requires locking! This is a major
issue. This is oxymoron because you wasted a lot of code and essentially
still
【在 g**e 的大作中提到】
: Write a special singleton class, the class has one integer field, make sure
: only one instance of this class will be instantiated for the same value of
: the integer field.
: jobhunting版有人给了个代码，我改了一下，高手看看对不对，谢谢. 用了double
: lock checking
: public class SpecialSingleton {
: private final int i;
: private volatile static SpecialSingleton instance = null;
: private static ConcurrentHashMap
: instanceMap = new ConcurrentHashMap();
|
s******n
发帖数: 876 | 24 the ConcurrentHashMap can be used for lockless lookup, without copying.
however, I bet the naive version I provided outperforms the sophisticated/
optimized ones on the commodity machines google uses. |
s*********g
发帖数: 2350 | 25 mark
sure
【在 g**e 的大作中提到】
: Write a special singleton class, the class has one integer field, make sure
: only one instance of this class will be instantiated for the same value of
: the integer field.
: jobhunting版有人给了个代码，我改了一下，高手看看对不对，谢谢. 用了double
: lock checking
: public class SpecialSingleton {
: private final int i;
: private volatile static SpecialSingleton instance = null;
: private static ConcurrentHashMap
: instanceMap = new ConcurrentHashMap();
|
