d*********g
发帖数: 38 | 1 小弟刚开始学，有一事不明。
如果用synchronized，可以保证一个对象不会被同时写入。但我觉得就算synchronized
还是会有问题。比如x，y两个线程同时读并且试图写一个变量v
Time 0
x<--(read)--v=3
y<--(read)--v=3
Time 1
x---(write v+1)--->v //v becomes 4 after write
y---(write v+1)--->v //failed, because v is locked by x
Time 2
y---(write v+1)--->v //v is still 4, because the value read by y is 3.
这样看来，虽然synchronized可以保护写不同时进行，但无非是推迟了y写入v的时间，
问题依然是存在的。
请问这个问题java有解决吗？ |
z****e
发帖数: 54598 | 2 这个学术上叫做读写锁，dirty read
你应该在数据库课上学过怎么搞transaction
java可以搞得跟db一样
在read的时候就lock，把read & write写入同一个method
然后synchronized这个method就好了，lock加在method所属的obj上
但是这还不是工业界的搞法
工业界的搞法是上vert.x, ejb, spring etc.
不要自己动手写concurrency
如果非要自己写，用java.util.concurrency |
g*****g
发帖数: 34805 | 3 Of course, AtomicInteger.
synchronized
【在 d*********g 的大作中提到】
: 小弟刚开始学，有一事不明。
: 如果用synchronized，可以保证一个对象不会被同时写入。但我觉得就算synchronized
: 还是会有问题。比如x，y两个线程同时读并且试图写一个变量v
: Time 0
: x<--(read)--v=3
: y<--(read)--v=3
: Time 1
: x---(write v+1)--->v //v becomes 4 after write
: y---(write v+1)--->v //failed, because v is locked by x
: Time 2
|
z*y
发帖数: 1311 | 4 Can you try putting "read/write" inside one synchronized block, no?
Like http://tutorials.jenkov.com/java-concurrency/synchronized.html |
w**z
发帖数: 8232 | 5 synchronized 保证你写进去的value 是准确的。没有synchronized, 一个Java
statement 可以不是 atomic, 几个instructions完成， 中间可能会被插入其他thread
的instructions, 造成你要写的那块memory 被搞乱了。
synchronized
【在 d*********g 的大作中提到】
: 小弟刚开始学，有一事不明。
: 如果用synchronized，可以保证一个对象不会被同时写入。但我觉得就算synchronized
: 还是会有问题。比如x，y两个线程同时读并且试图写一个变量v
: Time 0
: x<--(read)--v=3
: y<--(read)--v=3
: Time 1
: x---(write v+1)--->v //v becomes 4 after write
: y---(write v+1)--->v //failed, because v is locked by x
: Time 2
|
m****o
发帖数: 182 | 6 他这个情况直接用volatile就可以了，value change直接flush到main memory。
【在 g*****g 的大作中提到】
: Of course, AtomicInteger.
:
: synchronized
|
g*****g
发帖数: 34805 | 7 No, volatile cannot avoid race condition on add. It's fine on a boolean. And
you don't need to understand why.
At the end of the day, just use AtomicInteger and don't try to be super
smart. You'll never see the performance gain from here.
【在 m****o 的大作中提到】
: 他这个情况直接用volatile就可以了，value change直接flush到main memory。
|
s*i
发帖数: 5025 | 8 难道不是 Time2的时候， v 已经是 4了吗？
synchronized
[发表自未名空间手机版 - m.mitbbs.com]
【在 d*********g 的大作中提到】
: 小弟刚开始学，有一事不明。
: 如果用synchronized，可以保证一个对象不会被同时写入。但我觉得就算synchronized
: 还是会有问题。比如x，y两个线程同时读并且试图写一个变量v
: Time 0
: x<--(read)--v=3
: y<--(read)--v=3
: Time 1
: x---(write v+1)--->v //v becomes 4 after write
: y---(write v+1)--->v //failed, because v is locked by x
: Time 2
|
w**z
发帖数: 8232 | 9 古德霸是对的
http://stackoverflow.com/questions/9749746/what-is-the-differen
And
【在 g*****g 的大作中提到】
: No, volatile cannot avoid race condition on add. It's fine on a boolean. And
: you don't need to understand why.
: At the end of the day, just use AtomicInteger and don't try to be super
: smart. You'll never see the performance gain from here.
|
c*********e
发帖数: 16335 | 10 赵老师，synchronization 和 concurrency 不是一回事。
【在 z****e 的大作中提到】
: 这个学术上叫做读写锁，dirty read
: 你应该在数据库课上学过怎么搞transaction
: java可以搞得跟db一样
: 在read的时候就lock，把read & write写入同一个method
: 然后synchronized这个method就好了，lock加在method所属的obj上
: 但是这还不是工业界的搞法
: 工业界的搞法是上vert.x, ejb, spring etc.
: 不要自己动手写concurrency
: 如果非要自己写，用java.util.concurrency
|
|
|
c*********e
发帖数: 16335 | 11 读写锁有多种做法。比如说，你在读写一个数据库的表。
1。 读的时候锁住整个表，不让别的thread读这个表。
写的时候锁住整个表，不让别的thread写这个表。
读的锁不能变成写的锁;但是，写的锁可以变成读的锁。
2。读的时候不锁。
写的时候锁住整个表，不让别的thread写这个表。
3。 读的时候不锁。
写的时候只锁住要写的这一个record(row)，不让别的thread写这个record(row)，但是
可以写其它的record(row).
第3种情况，读的时候不锁，读的可能是写之前的老数据（静态的数据，不是reference
），也可能是读的当前的数据（读的是reference,指针指的地址的内容）
所以，这2个是不同的
ConcurrentHashMap vs Synchronized HashMap
synchronized
【在 d*********g 的大作中提到】
: 小弟刚开始学，有一事不明。
: 如果用synchronized，可以保证一个对象不会被同时写入。但我觉得就算synchronized
: 还是会有问题。比如x，y两个线程同时读并且试图写一个变量v
: Time 0
: x<--(read)--v=3
: y<--(read)--v=3
: Time 1
: x---(write v+1)--->v //v becomes 4 after write
: y---(write v+1)--->v //failed, because v is locked by x
: Time 2
|
c*********e
发帖数: 16335 | 12 volatile只能保证可见，但是不保证atomic.
【在 m****o 的大作中提到】
: 他这个情况直接用volatile就可以了，value change直接flush到main memory。
|
m****o
发帖数: 182 | 13 To guarantee atomicity, yes you have to use some sort of atomic data
structure. AtomicInteger will do in this case, which essentially does this,
val v = new AtomicInteger(3)
var cv = v.get()
while (v.compareAndSet(cv, cv + 1)) {
cv = v.get()
}
And
【在 g*****g 的大作中提到】
: No, volatile cannot avoid race condition on add. It's fine on a boolean. And
: you don't need to understand why.
: At the end of the day, just use AtomicInteger and don't try to be super
: smart. You'll never see the performance gain from here.
|
z****e
发帖数: 54598 | 14 靠，你太烂了
【在 c*********e 的大作中提到】
: 赵老师，synchronization 和 concurrency 不是一回事。
|
b***i
发帖数: 3043 | 15 不用吧？只要在一个class里面，同一个object的不同synchronized function都是不同
时的
【在 z*y 的大作中提到】
: Can you try putting "read/write" inside one synchronized block, no?
: Like http://tutorials.jenkov.com/java-concurrency/synchronized.html
|
c*********e
发帖数: 16335 | 16 你说说，这2个有啥区别：
ConcurrentHashMap vs Synchronized HashMap
【在 z****e 的大作中提到】
: 靠，你太烂了
|
z****e
发帖数: 54598 | 17
reference
Synchronized HashMap就是HashTable，除了api名字略有区别以外，早已经不用了
就用concurrenthashmap就好了，hashtable这都是上个世纪的玩意了
可以看出让你看那些thread safe的各种frameworks，还是一个都没看
【在 c*********e 的大作中提到】
: 读写锁有多种做法。比如说，你在读写一个数据库的表。
: 1。 读的时候锁住整个表，不让别的thread读这个表。
: 写的时候锁住整个表，不让别的thread写这个表。
: 读的锁不能变成写的锁;但是，写的锁可以变成读的锁。
: 2。读的时候不锁。
: 写的时候锁住整个表，不让别的thread写这个表。
: 3。 读的时候不锁。
: 写的时候只锁住要写的这一个record(row)，不让别的thread写这个record(row)，但是
: 可以写其它的record(row).
: 第3种情况，读的时候不锁，读的可能是写之前的老数据（静态的数据，不是reference
|
z****e
发帖数: 54598 | 18
这两个区别不是太明显了吧？
hashmap vs hashtable
concurrenthashmap vs hashmap
随便狗，这两个是经典的面试问题
【在 c*********e 的大作中提到】
: 你说说，这2个有啥区别：
: ConcurrentHashMap vs Synchronized HashMap
|
c*********e
发帖数: 16335 | 19 拜托，我问的是
ConcurrentHashMap vs Synchronized HashMap
【在 z****e 的大作中提到】
:
: 这两个区别不是太明显了吧？
: hashmap vs hashtable
: concurrenthashmap vs hashmap
: 随便狗，这两个是经典的面试问题
|
z****e
发帖数: 54598 | 20
靠，所以说你不行
Synchronized HashMap vs hashtable
这两个其实是一个东西，idea是一样的
Synchronized HashMap vs hashtable vs hashmap
这个应该是1.5时代最经典的面试题了
只要涉及到thread safe，一定问
还有arraylist vs vector
【在 c*********e 的大作中提到】
: 拜托，我问的是
: ConcurrentHashMap vs Synchronized HashMap
|
|
|
c*********e
发帖数: 16335 | 21 Synchronized HashMap：
Each method is synchronized using an object level lock. SO the get and
put methods on synchMap acquire a lock.
Locking the entire collection is a performance overhead. While one
thread holds on to the lock, no other thread can use the collection.
－－－－－－－－－－－－－－－－－－
ConcurrentHashMap was introduced in JDK 5.
There is no locking at the object level,The locking is at a much finer
granularity. For a concurrentHashMap, the locks may be at a hashmap bucket
level.
The effect of lower level locking is that you can have concurrent
readers and writers whilch is not possible for synchronized collections.
This leads to much more scalability.
ConcurrentHashMap does not throw a ConcurrentModificationException if
one thread tries to modify it while another is iterating over it.
http://stackoverflow.com/questions/1291836/concurrenthashmap-vs
【在 z****e 的大作中提到】
:
: 靠，所以说你不行
: Synchronized HashMap vs hashtable
: 这两个其实是一个东西，idea是一样的
: Synchronized HashMap vs hashtable vs hashmap
: 这个应该是1.5时代最经典的面试题了
: 只要涉及到thread safe，一定问
: 还有arraylist vs vector
|
z****e
发帖数: 54598 | 22
没错啊，你是不是没有认真看我在说什么啊？
hashtable就是Collections.synchronizedMap(hashmap)
这里有benchmark，自己看看是不是一个level的
http://crunchify.com/hashmap-vs-concurrenthashmap-vs-synchroniz
这里还有解释
http://stackoverflow.com/questions/8875680/difference-between-h
Collections.synchronizedMap(HashMap) ＝＝ HashTable
这两个都是时代的产物，legacy了
现在要用，就用ConcurrentHashMap
这么简单道理，重复了两三遍，怎么就不懂呢？
【在 c*********e 的大作中提到】
: Synchronized HashMap：
: Each method is synchronized using an object level lock. SO the get and
: put methods on synchMap acquire a lock.
: Locking the entire collection is a performance overhead. While one
: thread holds on to the lock, no other thread can use the collection.
: －－－－－－－－－－－－－－－－－－
: ConcurrentHashMap was introduced in JDK 5.
: There is no locking at the object level,The locking is at a much finer
: granularity. For a concurrentHashMap, the locks may be at a hashmap bucket
: level.
|
c*********e
发帖数: 16335 | 23 我是要你把2个的区别写出来，不是要你给我link.
【在 z****e 的大作中提到】
:
: 没错啊，你是不是没有认真看我在说什么啊？
: hashtable就是Collections.synchronizedMap(hashmap)
: 这里有benchmark，自己看看是不是一个level的
: http://crunchify.com/hashmap-vs-concurrenthashmap-vs-synchroniz
: 这里还有解释
: http://stackoverflow.com/questions/8875680/difference-between-h
: Collections.synchronizedMap(HashMap) ＝＝ HashTable
: 这两个都是时代的产物，legacy了
: 现在要用，就用ConcurrentHashMap
|
z****e
发帖数: 54598 | 24
靠，你说什么区别呢？
我不是最后一句说了嘛
如果要用，就用java.util.concurrency
你不会不知道ConcurrentHashMap就是其中一个最常用的类吧？
你说的synchronizedhashmap其实就是hashtable
只不过提供了一种方式把hashmap -> hashtable而不用改动api
这样可以直接做wrapper，而不用改动源代码
但是这个仅仅是api level的保留，本质上还是hashtable
所以hashtable vs concurrenthashmap
你这个区别不懂吗？
我估计你根本就没看懂我在说什么，我说的是syncrhonized method
跟下面这个人说的基本上一样，不是用synchronised hashmap
是类似
public synchronized void myFunc() {
read, incre, write etc.
}
我压根没说hashtable，因为已经凹凸很久了
所以你来告诉我这个不是一回事，我也是醉了
哪来的自信认为我不懂这个区别？
发信人: zyy (无聊（自由泳，众议院，众议员，中医院）), 信区: Programming
标 题: Re: Java concurrency的疑惑，难道我理解错了？
发信站: BBS 未名空间站 (Mon Aug 10 14:09:40 2015, 美东)
Can you try putting "read/write" inside one synchronized block, no?
Like http://tutorials.jenkov.com/java-concurrency/synchronized.html
【在 c*********e 的大作中提到】
: 我是要你把2个的区别写出来，不是要你给我link.
|
s*******l
发帖数: 110 | |
d*********g
发帖数: 38 | |
z****e
发帖数: 54598 | 27 把account单独提出来做成一个object
然后所有关于这个account的操作
无论是read，还是write，还是read+write
塞入这个object，然后声明所有的func为synchronized
就可以了
比如
public class Account{
private int balance;
public synchronized int check(){
return balance;
}
public synchronized void deposit(int cash){
this.balance += cash;
}
}
synchronized func 相当于synchronized(this){
...
}
public void synchronized func(){...}
等价于
public void func(){
synchronized(this){...}
}
syncrhonized意思就是对于后面这个object
所有的thread，无论做什么syncrhonized的操作
都是互斥的
因为这里只有一个balance
所以你直接syncrhonized(balance){...}也是可以的
这个本质上跟古德霸说的那个AtomicInteger是一样的
当然你可以直接用轮子，方便很多 |
z****e
发帖数: 54598 | 28 虽然你这么搞可以
但是现实生活中，对于threads之间的并发操作
还是能绕开就绕开，一般关键数据，如果你需要存储起来的话
交给db去做，用transaction可以很好滴完成任务
只有一些时效性非常强的才会需要你在内存中直接把这个搞定
比如游戏，比如real time pvp
但是游戏也不是完全没有办法绕开
fp的做法就是将线程之间需要分享的状态全部搞成immutable
就是thread内部，你爱怎么搞怎么搞，但是thread之间，如果你需要通信
必需immutable，这样就不怕并发了，这种可以解决real time gaming的pvp问题
用command pattern，操作方只能发送command给游戏主循环的thread
所有的command全部搞成immutable，反正也不大，这样就不存在并发更改问题了
做到这一步已经能解决99%的问题了，连游戏都能解决了
剩下1%，我很怀疑你会不会用到
如果你真碰到了，也尽量用java.util.concurrency里面的类
比如古德霸说的AtomicInteger，还有AtomicDouble etc.
而不是自己动手synchronized，我反正是没有遇到过这种问题 |
