如果我有一段关于synchronized的代码,比如: Class A { private double number = 0; public synchronized void setNumber(value) ( this.number = value; } public synchronized double getNumber() { return this.number; } } 这个时候,我没有对number用volatile的modifier,是不是会出现visibility的问题。 这里不会有两个tread同时setNumber,而且number我给了private,不会被class外面直 接修改。但是如果某个thread call setNumber修改了这个double的值,这里修改后的 number能不能被所有的thread看到? 或者我换个问法,假如某个thread用了setNumber(4), 结束之后另一个thread马上 调用getNumber(),返回的值,会不会一定是4? 在这种情况下,是不是应该同时使用synchronized和volatile? 恳请版上各位大神赐教!
i*u
3 楼
可以申请I-140,但提交I-485之前要办好J-1豁免。我的J-1客户就如此做的。
g*g
4 楼
It's a problem without volatile keyword. The recommended way today is to use AtomicDouble instead and you don't need to synchronize the methods.
【在 l******n 的大作中提到】 : 如果我有一段关于synchronized的代码,比如: : Class A { : private double number = 0; : public synchronized void setNumber(value) ( : this.number = value; : } : public synchronized double getNumber() { : return this.number; : } : }
l*n
5 楼
我也觉得是有问题,但是这和我从书上看来的矛盾: Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up to date values of shared mutable variables, the reading and writing threads must synchronize on a common lock. 这个意思我的理解就是synchronized可以保证visibility to all threads,但是这段 代码如果有问题,就跟这个意思矛盾。 synchronized可以确保两个thread不会call一个method,但是synchronized对于 visibility到底有没有作用?
use
【在 g*****g 的大作中提到】 : It's a problem without volatile keyword. The recommended way today is to use : AtomicDouble instead and you don't need to synchronize the methods.
g*g
6 楼
I didn't read the original post carefully. His example should work actually. But not the recommended way to do it. volatile is tricky, basically it works for getter/setter without sync. But Atomic is much easier.
【在 l******n 的大作中提到】 : 我也觉得是有问题,但是这和我从书上看来的矛盾: : Locking is not just about mutual exclusion; it is also about memory : visibility. To ensure that all threads see the most up to date values of : shared mutable variables, the reading and writing threads must synchronize : on a common lock. : 这个意思我的理解就是synchronized可以保证visibility to all threads,但是这段 : 代码如果有问题,就跟这个意思矛盾。 : synchronized可以确保两个thread不会call一个method,但是synchronized对于 : visibility到底有没有作用? :
w*z
7 楼
According the JSR-133, the code should work. But there is more to synchronization than mutual exclusion. Synchronization ensures that memory writes by a thread before or during a synchronized block are made visible in a predictable manner to other threads which synchronize on the same monitor. After we exit a synchronized block, we release the monitor, which has the effect of flushing the cache to main memory, so that writes made by this thread can be visible to other threads. Before we can enter a synchronized block, we acquire the monitor, which has the effect of invalidating the local processor cache so that variables will be reloaded from main memory. We will then be able to see all of the writes made visible by the previous release. http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#s for this case, you can use synchronized only on writes or atomic and define the variable as volatile. It might give you a slightly better performance.
actually.
【在 g*****g 的大作中提到】 : I didn't read the original post carefully. His example should work actually. : But not the recommended way to do it. : volatile is tricky, basically it works for getter/setter without sync. But : Atomic is much easier.
l*n
8 楼
谢谢你的回复! 我其实在thinking in java上面找到了类似的code,说不加volatile不行。 所以看起来这个是一个比较tricky的部分,应该尽量避免这样使用。
Synchronization block synchronize that of visible
【在 w**z 的大作中提到】 : According the JSR-133, the code should work. : But there is more to synchronization than mutual exclusion. Synchronization : ensures that memory writes by a thread before or during a synchronized block : are made visible in a predictable manner to other threads which synchronize : on the same monitor. After we exit a synchronized block, we release the : monitor, which has the effect of flushing the cache to main memory, so that : writes made by this thread can be visible to other threads. Before we can : enter a synchronized block, we acquire the monitor, which has the effect of : invalidating the local processor cache so that variables will be reloaded : from main memory. We will then be able to see all of the writes made visible