avatar
,还让人看电视吗# Joke - 肚皮舞运动
D*0
1
【 以下文字转载自 Java 讨论区 】
发信人: DK100 (dark knight), 信区: Java
标 题: java多线程问题请教
发信站: BBS 未名空间站 (Tue Jan 5 12:34:03 2016, 美东)
操作比较简单,就是有个cache,当cache miss时从数据库取值,同时更新cache。这里
的key是由两部分组成的,一个int和一个interface,函数输入是这两个。问题是在多
线程下如何synchronize。 我想是用concurrentHashMap当cache
Type是一个interface
一开始想用下面这个Key来做map的key,但是后来觉得不对,这也是想请教的一个地方
class Key {
public int a;
public Type t;
public Key(int a, Type t){...}
public int hashCode() {...}
public boolean equals(Key k) {... }
}
List f(int a, Type t) {
//这里如何synchronize
//我想用a和t组成一个string,然后用string来当key,然后synchronize在这个
string上
StringBuilder sb = new StringBuilder();
sb.append(a);
sb.append(t);
String key = sb.toString().intern();
synchronize(key) {

if(map.containsKey(key)){
return map.get(..);
}
// fetch corresponding value from database or some data source
map.put(key, value);
ret = value;
}
return ret;
}
不知道这么做对不对,合不合理,请多指教,谢谢。
avatar
b*i
2
NSC,
485 RD是10/15,FP schedule的是11/26,没有walk-in,已经FP了
请问大家有差不多时间RD的收到EAD/AP卡么?一直没有动静啊还
谢谢!
中间我改过一次地址,也不知道怎么查新的地址是不是生效了
该地址会delay combo卡么?
avatar
n*4
3
avatar
t*r
4
Why not use a reader writer lock?
avatar
x*7
5
RD 10/21 still waiting, so far nothing
avatar
f*t
6
草,盗老子的版,你申请版权了吗?
avatar
D*0
7
reader writer lock也是要lock在那个key上吧。这里一个问题是key是不是应该用
string,如果要是用一个新的class Key,那每次进来都要new一个新的Key的object,
然后lock在这个object,所以没起到作用,在多线程的情况下。不知道我想的对不对。

【在 t*********r 的大作中提到】
: Why not use a reader writer lock?
avatar
M*Z
8
我们的是RD后62天approve的,NSC
avatar
c*n
9
你那刷版忒狠了

【在 f***t 的大作中提到】
: 草,盗老子的版,你申请版权了吗?
avatar
p*p
10
不明白要sync什么?

reader writer lock也是要lock在那个key上吧。这里一个问题是key是不是应该用
string,如果要是用一个新的class Key,那每次进来都要new一个........

【在 D***0 的大作中提到】
: reader writer lock也是要lock在那个key上吧。这里一个问题是key是不是应该用
: string,如果要是用一个新的class Key,那每次进来都要new一个新的Key的object,
: 然后lock在这个object,所以没起到作用,在多线程的情况下。不知道我想的对不对。

avatar
R*9
11
you are still early, patient! usually it takes average 2 months to get EAD/
AP in NSC.
avatar
D*0
12
如果两个线程都访问同一组key(int和type的组合),这事一个先进来,看cache里没有,
就要去别的地方去拿,第二个线程这时expected是希望等着第一个线程把value算好了
,可以直接从cache里取,要不它也会同样
的去取这个key对应的value。

【在 p**p 的大作中提到】
: 不明白要sync什么?
:
: reader writer lock也是要lock在那个key上吧。这里一个问题是key是不是应该用
: string,如果要是用一个新的class Key,那每次进来都要new一个........

avatar
h*o
13
10/7 RD still initial review for AP and EAD
10/9 485 RD, 11/20 FP still acceptance.
avatar
w*e
14
既然每个thread进来之后都要new 一个新 key, 那么sync 根本就不管用,因为每人都
有自己的lock object。最简单的办法就是直接用
synchronize {
}
这样它是class level sync。
另外在sync block里面access IO绝对是个馊主意,比较好的办法是不要用sync,直接
check map, 如果没有的话,从db取出来,然后用putIfAbsent去放,这样即使别的
thread进行同样的操作,也没冲突。
avatar
k*1
15
同10/15,fp schedule 11/21,至今啥也没有。。。痛苦等待
avatar
D*0
16
不希望synchronize整个方法。。。,所以才想着用string做key,然后用string pool。

【在 w****e 的大作中提到】
: 既然每个thread进来之后都要new 一个新 key, 那么sync 根本就不管用,因为每人都
: 有自己的lock object。最简单的办法就是直接用
: synchronize {
: }
: 这样它是class level sync。
: 另外在sync block里面access IO绝对是个馊主意,比较好的办法是不要用sync,直接
: check map, 如果没有的话,从db取出来,然后用putIfAbsent去放,这样即使别的
: thread进行同样的操作,也没冲突。

avatar
B*n
17
485 rd 10/15 TSC
still waiting
avatar
D*0
18
关键是希望两个同时的访问同一个key的线程,其中一个去取数据,另外一个不用去取
,直接能从cache里拿另外一个取出来的结果

【在 w****e 的大作中提到】
: 既然每个thread进来之后都要new 一个新 key, 那么sync 根本就不管用,因为每人都
: 有自己的lock object。最简单的办法就是直接用
: synchronize {
: }
: 这样它是class level sync。
: 另外在sync block里面access IO绝对是个馊主意,比较好的办法是不要用sync,直接
: check map, 如果没有的话,从db取出来,然后用putIfAbsent去放,这样即使别的
: thread进行同样的操作,也没冲突。

avatar
b*i
19
请问大家现在有动静么?俺仍然在等

【在 b******i 的大作中提到】
: NSC,
: 485 RD是10/15,FP schedule的是11/26,没有walk-in,已经FP了
: 请问大家有差不多时间RD的收到EAD/AP卡么?一直没有动静啊还
: 谢谢!
: 中间我改过一次地址,也不知道怎么查新的地址是不是生效了
: 该地址会delay combo卡么?

avatar
h*d
20
在main里创建一个锁,pass到thread里。
每个thread,
...
上锁
访问数据库
解锁
...
[在 DK100 (dark knight) 的大作中提到:]
:【 以下文字转载自 Java 讨论区 】
:发信人: DK100 (dark knight), 信区: Java
:...........
avatar
b*n
21
这好像是我面试的时候被问到的一道题。。
你这样做是可以的,如果不想用String intern的话,可以用一个类似intern pool的
cache来maitain唯一的lock object,其实只是需要一个东西能提供putIfAbsent(),所
以你可以自己用一个ConcurrentHashMap来提供对应的lock object。
比如
ConcurrentHashMap locks;
// assume create new object is cheap.
Object uniqueLock = new Object();
Object lock = locks.putIfAbsent(key, uniqueLock);
uniqueLock = lock == null ? uniqueLock : lock;
synchronize(uniqueLock) {
......
}
不过这都是权宜之计。。其实最好的做法是提供一个callback,让你的cache自己处理
,当cache miss的时候自动call这个callback来load相应的data。
为啥不用Guava的Cache?这些功能貌似都提供了
avatar
j*o
22
你的thread只是read only吧,不需要做什么sync,查询DB的事情让别的process去做,
然后lock那个connection就好了。
avatar
t*r
23
Why? Concurrent reads are always safe. Concurrent writes generally requires
locking on the key's partition within the concurrent map anyways.

【在 D***0 的大作中提到】
: reader writer lock也是要lock在那个key上吧。这里一个问题是key是不是应该用
: string,如果要是用一个新的class Key,那每次进来都要new一个新的Key的object,
: 然后lock在这个object,所以没起到作用,在多线程的情况下。不知道我想的对不对。

avatar
D*0
24
希望访问不同key的线程互补干扰

【在 h********d 的大作中提到】
: 在main里创建一个锁,pass到thread里。
: 每个thread,
: ...
: 上锁
: 访问数据库
: 解锁
: ...
: [在 DK100 (dark knight) 的大作中提到:]
: :【 以下文字转载自 Java 讨论区 】
: :发信人: DK100 (dark knight), 信区: Java

avatar
D*0
25
想知道用reader writer lock的话怎么lock,可以保证不同key访问互不干扰,相同key
访问的话,如果miss,则只有一个线程去取数据,更新cache

requires

【在 t*********r 的大作中提到】
: Why? Concurrent reads are always safe. Concurrent writes generally requires
: locking on the key's partition within the concurrent map anyways.

avatar
D*0
26
是的,豆包大侠。
Guava不熟,面试时能用吗?

【在 b*****n 的大作中提到】
: 这好像是我面试的时候被问到的一道题。。
: 你这样做是可以的,如果不想用String intern的话,可以用一个类似intern pool的
: cache来maitain唯一的lock object,其实只是需要一个东西能提供putIfAbsent(),所
: 以你可以自己用一个ConcurrentHashMap来提供对应的lock object。
: 比如
: ConcurrentHashMap locks;
: // assume create new object is cheap.
: Object uniqueLock = new Object();
: Object lock = locks.putIfAbsent(key, uniqueLock);
: uniqueLock = lock == null ? uniqueLock : lock;

avatar
b*5
27
我怎么觉得你这个东西根本就不需要什么extra synchronization啊?
就用concurrent hash map, read的话, 根本就没有什么synchronization issue。不
同的key, read有什么干扰? 相同的key, 有什么干扰?
唯一的, 就是两个相同的key, 要从db去读。 你说,
你只想要一个thread 去db 读. why? why do u need that requirement?
如果两个thread, 去读db的话, 没什么问题。 你只需要putifabsent就可以了。

key

【在 D***0 的大作中提到】
: 想知道用reader writer lock的话怎么lock,可以保证不同key访问互不干扰,相同key
: 访问的话,如果miss,则只有一个线程去取数据,更新cache
:
: requires

avatar
D*0
28
就是说有两个thread同时要读相同的key,这里的key是一个int和一个interface,
expected的是只需要有个一thread去真正的取数据,其他的都用这个thread取回来的。
就是需要一个putIfAbsent,但是我想这里还是需要synchronization的吧,要不对同一
个key访问的话,会造成多个thread去读数据,然后更新cache。
这里也是我想问要是synchronize的话,应该synchronize在key上,而且这个key是不是
用string.intern()。如果每次进来都new一个新的Key的object,然后synchronize在这
个object上,完全没起到作用啊。

【在 b**********5 的大作中提到】
: 我怎么觉得你这个东西根本就不需要什么extra synchronization啊?
: 就用concurrent hash map, read的话, 根本就没有什么synchronization issue。不
: 同的key, read有什么干扰? 相同的key, 有什么干扰?
: 唯一的, 就是两个相同的key, 要从db去读。 你说,
: 你只想要一个thread 去db 读. why? why do u need that requirement?
: 如果两个thread, 去读db的话, 没什么问题。 你只需要putifabsent就可以了。
:
: key

avatar
b*n
29
我以为你是工作中要用的。。
面试时问这个的话,就是要考察这个实现吧,那估计就不能直接把Guava的
loadingcache直接拿来用了。
看了一下Guava的实现,貌似也不是这么做的,还是按照最早ConcurrentHashMap那样,
把整个table分成多个segment,每次还是需要锁整个的segment,比一把大锁锁全部还
是强点。。
lockfree的算法我谨慎的认为没有,因为这里的关键是load这个开销大的操作只想做一
次,即使用CAS也需要重复load,所以上面的做法应该就是最好的做法了。

【在 D***0 的大作中提到】
: 是的,豆包大侠。
: Guava不熟,面试时能用吗?

avatar
b*5
30
我觉得这个assumption: load这个开销大的操作只想做一次, this requirement
有点强迫。。。 现在nosql自身就带有cache layer, 同样的key,一个thread 去
query nosql后, nosql都有setting让那个row stay in memory... 另外一个
thread, 马上去query时, 不一定就是二倍的时间或者load

【在 b*****n 的大作中提到】
: 我以为你是工作中要用的。。
: 面试时问这个的话,就是要考察这个实现吧,那估计就不能直接把Guava的
: loadingcache直接拿来用了。
: 看了一下Guava的实现,貌似也不是这么做的,还是按照最早ConcurrentHashMap那样,
: 把整个table分成多个segment,每次还是需要锁整个的segment,比一把大锁锁全部还
: 是强点。。
: lockfree的算法我谨慎的认为没有,因为这里的关键是load这个开销大的操作只想做一
: 次,即使用CAS也需要重复load,所以上面的做法应该就是最好的做法了。

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。