HashMap cache - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

HashMap cache

HashMap cache# Java - 爪哇娇娃

f*a2009-11-19 08:11

1 楼

只有原来唱的，最近有娃没有空录音了
过节就得来个热闹喜庆的吧，王派的我学唱的都比较凄惨
悲剧的是我只能学着唱王派，这个范傅版本的太累了
尤其还得吼范派，我手忙脚乱了
http://frada.cnaudios.net/chorus/frada/YueOpera/mp3/frada-11shibaxiangsong.mp3
买一送一，大家都吼，我也吼，吼吼！！！！不要吓飞了！
http://frada.cnaudios.net/chorus/frada/PopSong/mp3/frada-Baibaili.mp3

g*g2009-11-19 08:11

2 楼

I am working on an extremely high load server and trying to
optimize performance.
We have a class for caching which is like
HashMap map;
synchronized getEnry(String key) {
Entry value = map.get(key);
if(value == null) {
//create entry
map.put(key, entry);
}
}
synchronized removeEntry(String key) {
map.remove(key)
}
There's no update operation.
Obviously this is like using Collections.synchronizedMap(map) everything has
to
run on single thread and the performance sucks.

s*y2009-11-19 08:11

3 楼

虽然我听过第一段，还是要说
实在是太赞了!
都很赞

【在 f***a 的大作中提到】

: 只有原来唱的，最近有娃没有空录音了
: 过节就得来个热闹喜庆的吧，王派的我学唱的都比较凄惨
: 悲剧的是我只能学着唱王派，这个范傅版本的太累了
: 尤其还得吼范派，我手忙脚乱了
: http://frada.cnaudios.net/chorus/frada/YueOpera/mp3/frada-11shibaxiangsong.mp3
: 买一送一，大家都吼，我也吼，吼吼！！！！不要吓飞了！
: http://frada.cnaudios.net/chorus/frada/PopSong/mp3/frada-Baibaili.mp3

F*n2009-11-19 08:11

4 楼

A simple change will improve your performance a lot:
Entry getEntry(String key) {
Entry value = map.getKey(key);
if (value == null) {
synchronized(map) {
value = map.getKey(key);
if (value == null) {
//create entry here;
}
}
}
return value;
}
void removeEntry(String key) {
if (map.containsKey(key) {
synchronized(map) {
map.remove(key);
}
}
}
In your code everybody gets a

【在 g*****g 的大作中提到】

: I am working on an extremely high load server and trying to
: optimize performance.
: We have a class for caching which is like
: HashMap map;
: synchronized getEnry(String key) {
: Entry value = map.get(key);
: if(value == null) {
: //create entry
: map.put(key, entry);
: }

r*r2009-11-19 08:11

5 楼

赞哪，还一人串几个角

【在 f***a 的大作中提到】

g*g2009-11-19 08:11

6 楼

You are using double check pattern, and while get is not
locking, add/update/remove does and isn't it better to use
ConcurrentHashMap where you can have multiple non-conflicting
update threads?

【在 F****n 的大作中提到】

: A simple change will improve your performance a lot:
: Entry getEntry(String key) {
: Entry value = map.getKey(key);
: if (value == null) {
: synchronized(map) {
: value = map.getKey(key);
: if (value == null) {
: //create entry here;
: }
: }

S*92009-11-19 08:11

7 楼

忘带耳机了吼得很给力吗

F*n2009-11-19 08:11

8 楼

First, you said you don't have update. If so, ConcurrentHashMap is not good
because the overhead of partitioning. Second, ConcurrentHashMap is not for
this purpose. It's for concurrent update. It does not check existing copy.
You still have to lock it otherwise you will have multiple concurrent
creations. Third, your double check pattern is not right.

【在 g*****g 的大作中提到】

: You are using double check pattern, and while get is not
: locking, add/update/remove does and isn't it better to use
: ConcurrentHashMap where you can have multiple non-conflicting
: update threads?

s*y2009-11-19 08:11

9 楼

给力极了我娘这样的越剧迷都会给包子的

【在 S****9 的大作中提到】

: 忘带耳机了吼得很给力吗

g*g2009-11-19 08:11

10 楼

I understand the ConcurrentHashMap overhead part, however,
you do want concurrent creations on different keys. Your implementation
blocks that, doesn't it?

good

【在 F****n 的大作中提到】

: First, you said you don't have update. If so, ConcurrentHashMap is not good
: because the overhead of partitioning. Second, ConcurrentHashMap is not for
: this purpose. It's for concurrent update. It does not check existing copy.
: You still have to lock it otherwise you will have multiple concurrent
: creations. Third, your double check pattern is not right.

S*92009-11-19 08:11

11 楼

一人分饰二角好听，戏曲都有那么个味道蛮勾人的。

F*n2009-11-19 08:11

12 楼

Then double check on ConcurrentHashMap with key locks.

【在 g*****g 的大作中提到】

: I understand the ConcurrentHashMap overhead part, however,
: you do want concurrent creations on different keys. Your implementation
: blocks that, doesn't it?
:
: good

B*72009-11-19 08:11

13 楼

这版真是藏龙卧虎啊

m*t2009-11-19 08:11

14 楼

Is Double Checked Lock no longer a broken pattern and
I somehow missed the news?

【在 g*****g 的大作中提到】

S*92009-11-19 08:11

15 楼

有龙有虎不成席，还得来大鱼或小黄鸡，以及米饭馒头花卷

【在 B******7 的大作中提到】

: 这版真是藏龙卧虎啊

g*g2009-11-19 08:11

16 楼

It's not since 1.5 and you put a volatile keyword on it,
that's what I've heard.

【在 m******t 的大作中提到】

: Is Double Checked Lock no longer a broken pattern and
: I somehow missed the news?

s*y2009-11-19 08:11

17 楼

好吧，我配合地问一下，大家爱喝什么酒啊

【在 S****9 的大作中提到】

: 有龙有虎不成席，还得来大鱼或小黄鸡，以及米饭馒头花卷

F*n2009-11-19 08:11

18 楼

It has been fixed. It's essentially a JVM problem not the pattern's.

【在 m******t 的大作中提到】

: Is Double Checked Lock no longer a broken pattern and
: I somehow missed the news?

w*02009-11-19 08:11

19 楼

赞，难怪经验值已是天籁之音了。

【在 f***a 的大作中提到】

m*t2009-11-19 08:11

20 楼

Oh I didn't miss _that_ news, but the fix only fixes (via a hack btw)
it when only the variable itself is involved in race conditions.
The case in discussion is different. The synchronization on
map access is to prevent race conditions on the internal
map data structure, not on the variable holding the lookup
result.

【在 F****n 的大作中提到】

: It has been fixed. It's essentially a JVM problem not the pattern's.

w*02009-11-19 08:11

21 楼

山东大馒头味道是好，几天不见刀老乡，估计是正挥汗如雨刻苦彩排中。俺也吼了几嗓
子，可是录了下来一听糁
得直起鸡皮疙瘩，真想捧场可实在上不了台面，就安心做个优秀的观众了，你下个节目
是啥，期待中。

【在 S****9 的大作中提到】

: 有龙有虎不成席，还得来大鱼或小黄鸡，以及米饭馒头花卷

F*n2009-11-19 08:11

22 楼

I think in the discussed case double check will NEVER be a problem on ANY
JVM. The problem JVM used to have is at thread stack. The Map data is in the
heap.

【在 m******t 的大作中提到】

:
: Oh I didn't miss _that_ news, but the fix only fixes (via a hack btw)
: it when only the variable itself is involved in race conditions.
: The case in discussion is different. The synchronization on
: map access is to prevent race conditions on the internal
: map data structure, not on the variable holding the lookup
: result.

u*u2009-11-19 08:11

23 楼

真好听，听得俺耳朵都软了

g*g2009-11-19 08:11

24 楼

What will be the problem if I do double check with key locks
on HashMap instead?

【在 F****n 的大作中提到】

: Then double check on ConcurrentHashMap with key locks.

S*92009-11-19 08:11

25 楼

桑心了
你就录这一句：我关键时刻掉链子对不起革命对不起大家我愿意奔别的才艺以弥补大
家心灵上蒙受的损失
另外FYI：你的刀老乡很守信我已经收到她的DEMO 这是什么精神混江湖靠的就是一个
字：义气

【在 w****0 的大作中提到】

: 山东大馒头味道是好，几天不见刀老乡，估计是正挥汗如雨刻苦彩排中。俺也吼了几嗓
: 子，可是录了下来一听糁
: 得直起鸡皮疙瘩，真想捧场可实在上不了台面，就安心做个优秀的观众了，你下个节目
: 是啥，期待中。

m*t2009-11-19 08:11

26 楼

the
I wouldn't be so sure. IIUC, the problem arises from a reference being
used before the object it points to is completely initialized. I don't see
how that has to do with where the data is.
I was also just reading the HashTable code from jdk 1.6. Looking
at get() and removeEntryForKey(), which span about 12 and 25 lines of code,
including a while loop, there is no way this doesn't require a strict
synchronization.

【在 F****n 的大作中提到】

: I think in the discussed case double check will NEVER be a problem on ANY
: JVM. The problem JVM used to have is at thread stack. The Map data is in the
: heap.

w*02009-11-19 08:11

27 楼

你一伤心我就慌心了，不是还有时间么，那我再练练，行不。先听
听刀妹妹的。
我又糊涂了，义气是俩字还是一个，或者藏着啥东西只有智商140
的才能看出来的。

奔别的才艺以弥补大
混江湖靠的就是一个

【在 S****9 的大作中提到】

: 桑心了
: 你就录这一句：我关键时刻掉链子对不起革命对不起大家我愿意奔别的才艺以弥补大
: 家心灵上蒙受的损失
: 另外FYI：你的刀老乡很守信我已经收到她的DEMO 这是什么精神混江湖靠的就是一个
: 字：义气

g*g2009-11-19 08:11

28 楼

ConcurrentHashMap has internal lock to do it, HashMap seems
to need an external lock in my opinion.

【在 m******t 的大作中提到】

:
: the
: I wouldn't be so sure. IIUC, the problem arises from a reference being
: used before the object it points to is completely initialized. I don't see
: how that has to do with where the data is.
: I was also just reading the HashTable code from jdk 1.6. Looking
: at get() and removeEntryForKey(), which span about 12 and 25 lines of code,
: including a while loop, there is no way this doesn't require a strict
: synchronization.

s*y2009-11-19 08:11

29 楼

不论多少个字，表达气概都可以说一个字的
哎，这是我在这个bbs上第一次这么那爱死

【在 w****0 的大作中提到】

: 你一伤心我就慌心了，不是还有时间么，那我再练练，行不。先听
: 听刀妹妹的。
: 我又糊涂了，义气是俩字还是一个，或者藏着啥东西只有智商140
: 的才能看出来的。
:
: 奔别的才艺以弥补大
: 混江湖靠的就是一个

m*t2009-11-19 08:11

30 楼

If it's for caching and you are not worried about updating, then
the objects cached can be considered immutable, then two objects
loaded by the same key would be logically equivalent and would stay
that way.
If that's the case, why not just skip synchronization all together.
Worse comes to worst two threads get two equivalent objects, right?

【在 g*****g 的大作中提到】

S*92009-11-19 08:11

31 楼

助教：强教授的意思是nice，就是奈斯

【在 s******y 的大作中提到】

: 不论多少个字，表达气概都可以说一个字的
: 哎，这是我在这个bbs上第一次这么那爱死

F*n2009-11-19 08:11

32 楼

The core of the double check pattern problem, is that when you assign a
newly created object to a field (which is on stack), the content of that
field on the stack may be out of synch. The volatile keyword fix it because
by declaring a field volatile, the content of that field will never be
cached on the stack.
If the variable is on the heap, there should be no problem.

【在 m******t 的大作中提到】

:
: If it's for caching and you are not worried about updating, then
: the objects cached can be considered immutable, then two objects
: loaded by the same key would be logically equivalent and would stay
: that way.
: If that's the case, why not just skip synchronization all together.
: Worse comes to worst two threads get two equivalent objects, right?

s*y2009-11-19 08:11

33 楼

老子的房顶又要不够了

【在 S****9 的大作中提到】

: 助教：强教授的意思是nice，就是奈斯

g*g2009-11-19 08:11

34 楼

Can't do that. It's not a simple class, it has references to other
classes. And while I am new on this system, I am afraid that might
lead to double creation of some other informations.

【在 m******t 的大作中提到】

r*r2009-11-19 08:11

35 楼

这句话助教怎么不注释了？

【在 s******y 的大作中提到】

: 老子的房顶又要不够了

F*n2009-11-19 08:11

36 楼

That equals to ConcurrentHashMap without double check.

【在 m******t 的大作中提到】

S*92009-11-19 08:11

37 楼

助教查文献没查到
“老子的房顶又不够了”
1. 老子是思想家？爹？自称？
2. 房顶是实指？象征？玻璃天花板？
3. 又：上次不够是什么时候？
4. 不够：房顶要几个才够

【在 r****r 的大作中提到】

: 这句话助教怎么不注释了？

F*n2009-11-19 08:11

38 楼

What about if two keys have same hash code?

【在 g*****g 的大作中提到】

: What will be the problem if I do double check with key locks
: on HashMap instead?

L*y2009-11-19 08:11

39 楼

古人云，三天不打，上房揭瓦。
教授格外如此。

【在 S****9 的大作中提到】

: 助教查文献没查到
: “老子的房顶又不够了”
: 1. 老子是思想家？爹？自称？
: 2. 房顶是实指？象征？玻璃天花板？
: 3. 又：上次不够是什么时候？
: 4. 不够：房顶要几个才够

g*g2009-11-19 08:11

40 楼

How is that related? When I lock on key.intern(),
don't you have to get the monitor on that key in the string pool
before you can access them? 2 different keys can have the same
hash code but how can they have the same monitor?
And two strings can't have the same hashcode right, otherwise
how can string be used as key?

【在 F****n 的大作中提到】

: What about if two keys have same hash code?

s*y2009-11-19 08:11

41 楼

你这话里，只有人字跟我有点关系

【在 L**********y 的大作中提到】

: 古人云，三天不打，上房揭瓦。
: 教授格外如此。

F*n2009-11-19 08:11

42 楼

I was not accurate. Same hash codes may not happen but it is possible
that two different hash codes are treated same in a hashmap. If you
look at the implementation of HashMap, it just & the the lower bits of
the hash code.
BTW, off course two strings can have the same hash code. The Hashtable
will use hash code as internal index, and they will do a Object.equals
to check if the key is the same.
For object that qualifies as keys, the only thing that must be assured
is that if two objects pass eq

【在 g*****g 的大作中提到】

: How is that related? When I lock on key.intern(),
: don't you have to get the monitor on that key in the string pool
: before you can access them? 2 different keys can have the same
: hash code but how can they have the same monitor?
: And two strings can't have the same hashcode right, otherwise
: how can string be used as key?

L*y2009-11-19 08:11

43 楼

那爱死也不用这么谦虚吗 //我强词夺理可都是你逼出来的阿

【在 s******y 的大作中提到】

: 你这话里，只有人字跟我有点关系

m*t2009-11-19 08:11

44 楼

because
OK, one of us is losing it. 8-)
In the basic test case demonstrating how the DCL is broken:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
The variable 'helper' is a member variable, which has to
be on the heap.

【在 F****n 的大作中提到】

: The core of the double check pattern problem, is that when you assign a
: newly created object to a field (which is on stack), the content of that
: field on the stack may be out of synch. The volatile keyword fix it because
: by declaring a field volatile, the content of that field will never be
: cached on the stack.
: If the variable is on the heap, there should be no problem.

s*y2009-11-19 08:11

45 楼

行行行，都怪我nice。。。搞得我都不知道正确的翻译到底是啥了

【在 L**********y 的大作中提到】

: 那爱死也不用这么谦虚吗 //我强词夺理可都是你逼出来的阿

g*g2009-11-19 08:11

46 楼

OK, I get what you are saying, but you still doesn't explain
how could a monitor on key.intern() fail for sync purpose.

【在 F****n 的大作中提到】

: I was not accurate. Same hash codes may not happen but it is possible
: that two different hash codes are treated same in a hashmap. If you
: look at the implementation of HashMap, it just & the the lower bits of
: the hash code.
: BTW, off course two strings can have the same hash code. The Hashtable
: will use hash code as internal index, and they will do a Object.equals
: to check if the key is the same.
: For object that qualifies as keys, the only thing that must be assured
: is that if two objects pass eq

f*a2009-11-19 08:11

47 楼

难道你要上房揭瓦来砸我？？？
不会难听到连你家房顶揭光了你还没砸消气？？？

【在 s******y 的大作中提到】

: 老子的房顶又要不够了

F*n2009-11-19 08:11

48 楼

I think a member variable is on the thread's stack, not heap. The JVM's
memory model is like this: The common heap contains block memory and non-
field objects, and a stack per thread that contains member variables (fields
). The problem is that when you initialize a field in an unsynchronized
block, other threads may "see it" before the field is completely initialized
. You don't have that problem in the heap.

【在 m******t 的大作中提到】

:
: because
: OK, one of us is losing it. 8-)
: In the basic test case demonstrating how the DCL is broken:
: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
: The variable 'helper' is a member variable, which has to
: be on the heap.

s*y2009-11-19 08:11

49 楼

师妹，大过节的我，我，我干什么了惹得你这么生气

【在 f***a 的大作中提到】

: 难道你要上房揭瓦来砸我？？？
: 不会难听到连你家房顶揭光了你还没砸消气？？？

g*g2009-11-19 08:11

50 楼

It's not a heap or stack thing. It's that the object construction
may not have finished in one thread and it's seen existing already
for another thread.

【在 m******t 的大作中提到】

i*i2009-11-19 08:11

51 楼

小艾狂点头ing

【在 S****9 的大作中提到】

m*t2009-11-19 08:11

52 楼

Yeah, I think there is an implementation of Map with an external lock.
And it's called HashTable. ;-)

【在 g*****g 的大作中提到】

: ConcurrentHashMap has internal lock to do it, HashMap seems
: to need an external lock in my opinion.

S*92009-11-19 08:11

53 楼

你再给刀刀示范一下义气吧来段评书五的

【在 i*i 的大作中提到】

: 小艾狂点头ing

F*n2009-11-19 08:11

54 楼

If you have two keys with same hash codes or same internal codes they are
basically unsynchronized, right?

【在 g*****g 的大作中提到】

: OK, I get what you are saying, but you still doesn't explain
: how could a monitor on key.intern() fail for sync purpose.

w*02009-11-19 08:11

55 楼

Lol, frada妹妹不知道强教授道行太深，说话艰涩到连智商二百的小酒助教都哭着辞职
不干了。那句话绝不是冲着
你来滴，你的歌喉的美丽，用言语难以表达，尤其是唱越剧的时候。

【在 f***a 的大作中提到】

: 难道你要上房揭瓦来砸我？？？
: 不会难听到连你家房顶揭光了你还没砸消气？？？

F*n2009-11-19 08:11

56 楼

When you say "initialize" in one thread you are referring to the private
stack that thread holds.

【在 g*****g 的大作中提到】

: It's not a heap or stack thing. It's that the object construction
: may not have finished in one thread and it's seen existing already
: for another thread.

w*02009-11-19 08:11

57 楼

要不小艾唱个歌，她嗓子柔柔甜甜的，唱个情歌啥的肯定好听。

【在 S****9 的大作中提到】

: 你再给刀刀示范一下义气吧来段评书五的

g*g2009-11-19 08:11

58 楼

Not if the performance matters. Just saying. HashTable is thread-safe
but nothing is really CONCURRENT.

【在 m******t 的大作中提到】

:
: Yeah, I think there is an implementation of Map with an external lock.
: And it's called HashTable. ;-)

S*92009-11-19 08:11

59 楼

看明白了你暗示小强IQ比200高50。

【在 w****0 的大作中提到】

: Lol, frada妹妹不知道强教授道行太深，说话艰涩到连智商二百的小酒助教都哭着辞职
: 不干了。那句话绝不是冲着
: 你来滴，你的歌喉的美丽，用言语难以表达，尤其是唱越剧的时候。

m*t2009-11-19 08:11

60 楼

fields
Could you give me a link on details about this so I can make sure I
really understand what you are saying, because as of now I'm taking it
as you are saying that member variables are the same as thread locals?
initialized

【在 F****n 的大作中提到】

: I think a member variable is on the thread's stack, not heap. The JVM's
: memory model is like this: The common heap contains block memory and non-
: field objects, and a stack per thread that contains member variables (fields
: ). The problem is that when you initialize a field in an unsynchronized
: block, other threads may "see it" before the field is completely initialized
: . You don't have that problem in the heap.

S*92009-11-19 08:11

61 楼

严重支持哦也

【在 w****0 的大作中提到】

: 要不小艾唱个歌，她嗓子柔柔甜甜的，唱个情歌啥的肯定好听。

g*g2009-11-19 08:11

62 楼

What does object monitor synchronization uses have to do with hashcode?
The problem with key.intern() I would think is causing racing in different
places of system if multiple places are using it, but it's certainly
thread-safe.

【在 F****n 的大作中提到】

: If you have two keys with same hash codes or same internal codes they are
: basically unsynchronized, right?

i*i2009-11-19 08:11

63 楼

我端着板凳等着你们大家呢

【在 w****0 的大作中提到】

: 要不小艾唱个歌，她嗓子柔柔甜甜的，唱个情歌啥的肯定好听。

m*t2009-11-19 08:11

64 楼

That's how I understand it too, but Foxman is saying that it wouldn't
be a problem in this case because of stack vs. heap. That's how this
has become "a head or stack thing" now. 8-)

【在 g*****g 的大作中提到】

: It's not a heap or stack thing. It's that the object construction
: may not have finished in one thread and it's seen existing already
: for another thread.

s*y2009-11-19 08:11

65 楼

给你们透露一个隐私，我被人喊“250的小强”喊了四年，真事。

【在 S****9 的大作中提到】

: 看明白了你暗示小强IQ比200高50。

F*n2009-11-19 08:11

66 楼

No, I said if a field is not declared volatile it will be cached in local.
Basically thread locals are caches of the common heap.

【在 m******t 的大作中提到】

:
: That's how I understand it too, but Foxman is saying that it wouldn't
: be a problem in this case because of stack vs. heap. That's how this
: has become "a head or stack thing" now. 8-)

r*r2009-11-19 08:11

67 楼

没雕刻个什么作为纪念么

【在 s******y 的大作中提到】

: 给你们透露一个隐私，我被人喊“250的小强”喊了四年，真事。

m*t2009-11-19 08:11

68 楼

Well, I'm going to take a big step back and ask you the obvious here:
have you done profiling and made sure that the old school, straightforward,
thread-safe synchronized block is the root cause of your performance
problem?
If you are new to the project, probably a good idea to stay with a safe
but maybe less performant solution.

【在 g*****g 的大作中提到】

: Not if the performance matters. Just saying. HashTable is thread-safe
: but nothing is really CONCURRENT.

s*y2009-11-19 08:11

69 楼

你的意思是刻个门牌号？

【在 r****r 的大作中提到】

: 没雕刻个什么作为纪念么

g*g2009-11-19 08:11

70 楼

Yes, we take a snapshot on JVM every 30 minutes. And we see
threads are getting blocked
Id:595
Name:J-379
State:BLOCKED on [email protected] owned by J-382
Stack trace:
......
Of course this may not be the biggest bottleneck for performance per se.
But it's obviously I need to do something about it. If not for real
performance gain, getting it out of picture will prove I am actually
doing something.

【在 m******t 的大作中提到】

:
: Well, I'm going to take a big step back and ask you the obvious here:
: have you done profiling and made sure that the old school, straightforward,
: thread-safe synchronized block is the root cause of your performance
: problem?
: If you are new to the project, probably a good idea to stay with a safe
: but maybe less performant solution.

r*r2009-11-19 08:11

71 楼

门牌号不够坚强。刻个坚强的代表么，比如金刚钻

【在 s******y 的大作中提到】

: 你的意思是刻个门牌号？

m*t2009-11-19 08:11

72 楼

I think we have some confusion in terminology. When you say
"cached in thread local", you mean the cache of the _processor
core_ that happens to be executing the thread, which, allow
me for insisting with my terminology, is yet another heap,
only smaller.
I took you to mean "thread local" as in:
http://java.sun.com/javase/6/docs/api/java/lang/ThreadLocal.html
Well, back to our original point, I do still believe that the same
situation applies to HashTable, as the internal data structure of
Hash

【在 F****n 的大作中提到】

: No, I said if a field is not declared volatile it will be cached in local.
: Basically thread locals are caches of the common heap.

s*y2009-11-19 08:11

73 楼

你别说，我还真抛过钻石，就是cut出多面体的形状。经过我手的大约共计有10 carats
的小钻

【在 r****r 的大作中提到】

: 门牌号不够坚强。刻个坚强的代表么，比如金刚钻

m*t2009-11-19 08:11

74 楼

But what about throughput and average response time _per thread_?
We constantly see a couple of synchronization spots in our
thread dumps as well, but every time it's a different thread holding it.
And because it's on the typical code path, with around 50 user threads
in the vm all the time, there is almost always some thread holding it.
But then from each individual thread's stand point, they almost never
spend a lot of time waiting on the lock, so I don't really consider it
a truly serialized

【在 g*****g 的大作中提到】

: Yes, we take a snapshot on JVM every 30 minutes. And we see
: threads are getting blocked
: Id:595
: Name:J-379
: State:BLOCKED on [email protected] owned by J-382
: Stack trace:
: ......
: Of course this may not be the biggest bottleneck for performance per se.
: But it's obviously I need to do something about it. If not for real
: performance gain, getting it out of picture will prove I am actually

f*a2009-11-19 08:11

75 楼

没pp没真相！！！
btw，本站还有比我老的？？？！
我觉得总数应该很少，难道都进这个贴子了？？？

【在 s******y 的大作中提到】

: 你别说，我还真抛过钻石，就是cut出多面体的形状。经过我手的大约共计有10 carats
: 的小钻

F*n2009-11-19 08:11

76 楼

Sorry for the terminology. It should the thread's local stack. ThreadLocal
is actually a class to access that stack.

【在 m******t 的大作中提到】

: But what about throughput and average response time _per thread_?
: We constantly see a couple of synchronization spots in our
: thread dumps as well, but every time it's a different thread holding it.
: And because it's on the typical code path, with around 50 user threads
: in the vm all the time, there is almost always some thread holding it.
: But then from each individual thread's stand point, they almost never
: spend a lot of time waiting on the lock, so I don't really consider it
: a truly serialized

s*y2009-11-19 08:11

77 楼

师妹，你今天标点符号喝多了来这里散散？
我是1998年上这个站的。当然，那个时候我可以在上幼稚园

【在 f***a 的大作中提到】

: 没pp没真相！！！
: btw，本站还有比我老的？？？！
: 我觉得总数应该很少，难道都进这个贴子了？？？

F*n2009-11-19 08:11

78 楼

No it's not. Imagine two key with same hashcodes (or internal address codes
). They are not synchronized. So when you remove one from the bucket the
other one may be appended after the removed one.

【在 g*****g 的大作中提到】

: What does object monitor synchronization uses have to do with hashcode?
: The problem with key.intern() I would think is causing racing in different
: places of system if multiple places are using it, but it's certainly
: thread-safe.

L*y2009-11-19 08:11

79 楼

你的手有没有被钻石硌疼？那得是多么复杂的心情啊

carats

【在 s******y 的大作中提到】

: 你别说，我还真抛过钻石，就是cut出多面体的形状。经过我手的大约共计有10 carats
: 的小钻

g*g2009-11-19 08:11

80 楼

I believe for this piece of code we usually configure 200
worker threads thread pool, so while blocking is not always
a performance issue for the overall system, we do want to
minimize the synchronized scope and sync on a function is
almost never the right thing to do.

【在 m******t 的大作中提到】

f*a2009-11-19 08:11

81 楼

我一直标点符号多
手写输入写字太累，逮个机会大把撒标点
98年我也上bbs，不过是水木。

【在 s******y 的大作中提到】

: 师妹，你今天标点符号喝多了来这里散散？
: 我是1998年上这个站的。当然，那个时候我可以在上幼稚园

m*t2009-11-19 08:11

82 楼

I wouldn't make a technically subtle fix unless I'm sure
what it fixes is going to be worth the risk.

【在 g*****g 的大作中提到】

: I believe for this piece of code we usually configure 200
: worker threads thread pool, so while blocking is not always
: a performance issue for the overall system, we do want to
: minimize the synchronized scope and sync on a function is
: almost never the right thing to do.

s*y2009-11-19 08:11

83 楼

不是很复杂。心思主要是集中在检查钻石有没有气泡和裂痕中

【在 L**********y 的大作中提到】

: 你的手有没有被钻石硌疼？那得是多么复杂的心情啊
:
: carats

m*t2009-11-19 08:11

84 楼

codes
Right, not to mention also the bucket itself could be changed
and synch'ing on the hash value itself mostly certainly won't
cover that.

【在 F****n 的大作中提到】

: No it's not. Imagine two key with same hashcodes (or internal address codes
: ). They are not synchronized. So when you remove one from the bucket the
: other one may be appended after the removed one.

s*y2009-11-19 08:11

85 楼

湖心亭上那些咿咿呀呀唱昆曲的孩子们中有你没？

【在 f***a 的大作中提到】

: 我一直标点符号多
: 手写输入写字太累，逮个机会大把撒标点
: 98年我也上bbs，不过是水木。

g*g2009-11-19 08:11

86 楼

OK, I get that, thanks. I wasn't thinking inside of HashMap
implementation.

【在 m******t 的大作中提到】

:
: codes
: Right, not to mention also the bucket itself could be changed
: and synch'ing on the hash value itself mostly certainly won't
: cover that.

S*92009-11-19 08:11

87 楼

好有诗意啊

【在 s******y 的大作中提到】

: 湖心亭上那些咿咿呀呀唱昆曲的孩子们中有你没？

k*r2009-11-19 08:11

88 楼

There are other problems. The conclusion so far is it's
still broken, and pretty much unfixable.

【在 g*****g 的大作中提到】

: It's not since 1.5 and you put a volatile keyword on it,
: that's what I've heard.

f*a2009-11-19 08:11

89 楼

我连票友都算不上呢，水平太差
不过我也看过两次他们排练
厚脸皮说也同台演出过，当然是龙套。

【在 s******y 的大作中提到】

: 湖心亭上那些咿咿呀呀唱昆曲的孩子们中有你没？

F*n2009-11-19 08:11

90 楼

I don't understand why they say double check is algorithmically incorrect.

【在 k***r 的大作中提到】

: There are other problems. The conclusion so far is it's
: still broken, and pretty much unfixable.

s*y2009-11-19 08:11

91 楼

当我没听过两边我都听过啦
你就不要谦虚了

【在 f***a 的大作中提到】

: 我连票友都算不上呢，水平太差
: 不过我也看过两次他们排练
: 厚脸皮说也同台演出过，当然是龙套。

r*r2009-11-19 08:11

92 楼

小强我忘了问你了，你抛光钻石用什么工具？

【在 s******y 的大作中提到】

: 当我没听过两边我都听过啦
: 你就不要谦虚了

s*y2009-11-19 08:11

93 楼

抛钻石啊鹿鹿当然是用钻石啦

【在 r****r 的大作中提到】

: 小强我忘了问你了，你抛光钻石用什么工具？

r*r2009-11-19 08:11

94 楼

努力想象中。。。那你怎么有把握要抛的对象被削掉而不是工具被磨掉

【在 s******y 的大作中提到】

: 抛钻石啊鹿鹿当然是用钻石啦

f*a2009-11-19 08:11

95 楼

京昆社高人很多
我们同台演出那次就很惊艳他们。

【在 s******y 的大作中提到】

: 当我没听过两边我都听过啦
: 你就不要谦虚了

f*a2009-11-19 08:11

96 楼

抛钻石干嘛？手工艺爱好者？

【在 s******y 的大作中提到】

: 抛钻石啊鹿鹿当然是用钻石啦

s*y2009-11-19 08:11

97 楼

还行。我也是从小听戏听到大的。
几年前听你唱王派就很惊艳

【在 f***a 的大作中提到】

: 京昆社高人很多
: 我们同台演出那次就很惊艳他们。

s*y2009-11-19 08:11

98 楼

工作需要。不过我是手工艺爱好者，人生最大理想是做一个木匠

【在 f***a 的大作中提到】

: 抛钻石干嘛？手工艺爱好者？

L*y2009-11-19 08:11

99 楼

网上小说说木匠得会捉鬼避邪，你敢吗？

【在 s******y 的大作中提到】

: 工作需要。不过我是手工艺爱好者，人生最大理想是做一个木匠

s*y2009-11-19 08:11

100 楼

网上小说说不长记性就会被当鬼捉，你能改么？

【在 L**********y 的大作中提到】

: 网上小说说木匠得会捉鬼避邪，你敢吗？

L*y2009-11-19 08:11

101 楼

蒙谁啊，根本没这么一说。你先创作一篇这样的网上小说来

【在 s******y 的大作中提到】

: 网上小说说不长记性就会被当鬼捉，你能改么？

s*y2009-11-19 08:11

102 楼

你也知道可以创作啊所以网络小说当不得真，而我想当木匠的心愿是很真切的
可惜

【在 L**********y 的大作中提到】

: 蒙谁啊，根本没这么一说。你先创作一篇这样的网上小说来

S*92009-11-19 08:11

103 楼

你奔个小说我放你一马

【在 s******y 的大作中提到】

: 你也知道可以创作啊所以网络小说当不得真，而我想当木匠的心愿是很真切的
: 可惜

s*y2009-11-19 08:11

104 楼

我不奔小说你送我一马？

【在 S****9 的大作中提到】

: 你奔个小说我放你一马

s*y2009-11-19 08:11

105 楼

用来磨钻石的工具的表面是人工生长的钻石。工具可以旋转，通过调节压力和旋转的速度来把握抛钻石的快慢。如果钻石没有明显的气泡和裂痕的话，一个上午我大概可以把一个0.5克拉的钻石抛出一个介于“old single cut”和“round brilliant cut”之间的类型出来。
不过这里我又忽悠了。我需要抛的是钻石的小头，就是尖的那一端：工作需要。如果是正常的大头，抛的时间会大大延长。

【在 r****r 的大作中提到】

: 努力想象中。。。那你怎么有把握要抛的对象被削掉而不是工具被磨掉

r*r2009-11-19 08:11

106 楼

GRE逻辑：从以上一段话我们可得出以下结论：人工生长的钻石（PS：这是什么东西？
）的硬度>被抛的钻石（天然生长的？）。可以得分么？
小强你可以看出钻石里的气泡？牛啊，是用那种贴在眼睛上的放大镜看的么？

速度来把握抛钻石的快慢。如果钻石没有明显的气泡和裂痕的话，一个上午我大概可以
把一个0.5克拉的钻石抛出一个介于“old single cut”和“round brilliant cut”之
间的类型出来。
是正常的大头，抛的时间会大大延长。

【在 s******y 的大作中提到】

: 用来磨钻石的工具的表面是人工生长的钻石。工具可以旋转，通过调节压力和旋转的速度来把握抛钻石的快慢。如果钻石没有明显的气泡和裂痕的话，一个上午我大概可以把一个0.5克拉的钻石抛出一个介于“old single cut”和“round brilliant cut”之间的类型出来。
: 不过这里我又忽悠了。我需要抛的是钻石的小头，就是尖的那一端：工作需要。如果是正常的大头，抛的时间会大大延长。

s*y2009-11-19 08:11

107 楼

其实是互相磨，都有损耗。钻石里的气泡很容易看见，一般的放大倍数不高的光学显微
镜就可以。
你去珠宝店，很多晶体都分天然生长的和人工生长的，区别么，就是前者价钱比后者高
，后者品质比前者高。不过买这些东西的，都是买个难得罢了。

【在 r****r 的大作中提到】

: GRE逻辑：从以上一段话我们可得出以下结论：人工生长的钻石（PS：这是什么东西？
: ）的硬度>被抛的钻石（天然生长的？）。可以得分么？
: 小强你可以看出钻石里的气泡？牛啊，是用那种贴在眼睛上的放大镜看的么？
:
: 速度来把握抛钻石的快慢。如果钻石没有明显的气泡和裂痕的话，一个上午我大概可以
: 把一个0.5克拉的钻石抛出一个介于“old single cut”和“round brilliant cut”之
: 间的类型出来。
: 是正常的大头，抛的时间会大大延长。