F****n
发帖数: 3271 | 1 is as simple as the following:
Map map = new CocurrentHashMap();
Entry getEntry(String key) {
Entry value = map.getKey(key);
if (value == null) {
synchronized(key) {
value = map.getKey(key);
if (value == null) {
value = new Entry();
map.put(key, value);
}
}
}
return value;
}
void removeEntry(String key) {
if (map.containsKey(key) {
synchronized(key) {
if (map.containsKe |
g*****g
发帖数: 34805 | 2 When you do synchronized(key), potentially you can
block totally unrelated threads in the system if
the key is the same elsewhere.
【在 F****n 的大作中提到】
: is as simple as the following:
: Map map = new CocurrentHashMap();
: Entry getEntry(String key) {
: Entry value = map.getKey(key);
: if (value == null) {
: synchronized(key) {
: value = map.getKey(key);
: if (value == null) {
: value = new Entry();
: map.put(key, value);
|
t*****s
发帖数: 124 | 3
does sync key make any sense?
【在 F****n 的大作中提到】
: is as simple as the following:
: Map map = new CocurrentHashMap();
: Entry getEntry(String key) {
: Entry value = map.getKey(key);
: if (value == null) {
: synchronized(key) {
: value = map.getKey(key);
: if (value == null) {
: value = new Entry();
: map.put(key, value);
|
F****n
发帖数: 3271 | 4 You are right but how likely is that, compared with simplicity of the solution.
【在 g*****g 的大作中提到】
: When you do synchronized(key), potentially you can
: block totally unrelated threads in the system if
: the key is the same elsewhere.
|
F****n
发帖数: 3271 | 5 Yes it does.
【在 t*****s 的大作中提到】
:
: does sync key make any sense?
|
s******n
发帖数: 876 | 6 sync on key.inern() works - however the memory and performance implication
could be be very bad. I won't use it in a long running app.
a solution: create a set of strings representing locks. o
to acquire() a lock, if the set already has a string of same value, wait(
) on it; otherwise, put the string in the set, and return.
to release() a lock, remove the string from the set, and notify().
this should be really quick. the set is minimal.
【在 t*****s 的大作中提到】
:
: does sync key make any sense?
|
g*****g
发帖数: 34805 | 7 Well, if you are using it as a generic solution like hashmap,
I like the way Memozer gives you, a clean interface, no worry
about potential risk.
solution.
【在 F****n 的大作中提到】
: You are right but how likely is that, compared with simplicity of the solution.
|
m******t
发帖数: 2416 | 8 Is it necessary to call contains(key) again inside
the synchronized block?
【在 F****n 的大作中提到】
: is as simple as the following:
: Map map = new CocurrentHashMap();
: Entry getEntry(String key) {
: Entry value = map.getKey(key);
: if (value == null) {
: synchronized(key) {
: value = map.getKey(key);
: if (value == null) {
: value = new Entry();
: map.put(key, value);
|
g*****g
发帖数: 34805 | 9 I could be wrong but I think there's no need to sync
removal at all as ConcurrentHashMap guarrantees last
completed updated value on get. This means you may
have a retrieval that's not existent in map when you are using
it, but you won't screw the data structure due to it.
【在 m******t 的大作中提到】
: Is it necessary to call contains(key) again inside
: the synchronized block?
|
g*****g
发帖数: 34805 | 10 I think a simple trick may be prefixing the full path of
class for the key and call intern(), that should resolve the problem.
solution.
【在 F****n 的大作中提到】
: You are right but how likely is that, compared with simplicity of the solution.
|
