Y*G
2 楼
对于volatile成员,java只是标注一下
比如
public class App {
volatile int a = 1;
...
}
用javap看byte code,
...
volatile int a;
flags: ACC_VOLATILE
我以前猜java会对于volatile产生优化的代码,比如
public class App {
volatile int a = 1;
public static void main(String[] args) {
App app = new App();
int x = app.a;
System.out.printf("%d%n", x);
x = app.a;
System.out.printf("%d%n", x);
}
}
但是实际上,在第二次 "x = app.a"的时候,java产生同第一次"x = app.a"相同的代
码。这是,俺猜恍然大悟,优化是在运行的时候做的,而不是在编译的时候做的。
另外,赋值操作已经是原子操作了。如果你增加setA和getA函数,完全没有必要加
synchronize关键字。但是你如果要实现其他操作,比如addA(int delta),那你就需要
synchronize关键字了。
比如
public class App {
volatile int a = 1;
...
}
用javap看byte code,
...
volatile int a;
flags: ACC_VOLATILE
我以前猜java会对于volatile产生优化的代码,比如
public class App {
volatile int a = 1;
public static void main(String[] args) {
App app = new App();
int x = app.a;
System.out.printf("%d%n", x);
x = app.a;
System.out.printf("%d%n", x);
}
}
但是实际上,在第二次 "x = app.a"的时候,java产生同第一次"x = app.a"相同的代
码。这是,俺猜恍然大悟,优化是在运行的时候做的,而不是在编译的时候做的。
另外,赋值操作已经是原子操作了。如果你增加setA和getA函数,完全没有必要加
synchronize关键字。但是你如果要实现其他操作,比如addA(int delta),那你就需要
synchronize关键字了。
h*e
3 楼
哦,大家有在etsy上有店的吗? :)
l*n
4 楼
我的理解,getA()和setA()应该不是原子操作,这个在thinking in java 上面特意拿
出来一个例子强调了一下,会出问题的。我明天去另一个电脑找一下然后贴上来。
出来一个例子强调了一下,会出问题的。我明天去另一个电脑找一下然后贴上来。
p*y
5 楼
etsy要卖的出去我觉得是要有特色,要是没特色那就碰运气
Y*G
8 楼
are you sure?
http://fuseyism.com/classpath/doc/java/util/concurrent/atomic/A
JDK code does not use synchronize keywork in set method:
77: /**
78: * Sets to the given value.
79: *
80: * @param newValue the new value
81: */
82: public final void set(long newValue) {
83: value = newValue;
84: }
85:
【在 w**z 的大作中提到】
: long 的read 不是atomic, int是。
http://fuseyism.com/classpath/doc/java/util/concurrent/atomic/A
JDK code does not use synchronize keywork in set method:
77: /**
78: * Sets to the given value.
79: *
80: * @param newValue the new value
81: */
82: public final void set(long newValue) {
83: value = newValue;
84: }
85:
【在 w**z 的大作中提到】
: long 的read 不是atomic, int是。
p*y
9 楼
其实卖韩式怎么说呢,还是满讨巧的,做起来巨容易,基本没有手工技巧,而且买的人
还不少
话说我换版的韩饰怎么没人要,跟风进了点零件,我自己其实不是韩饰控,这下好了,
都屯在家里了
还不少
话说我换版的韩饰怎么没人要,跟风进了点零件,我自己其实不是韩饰控,这下好了,
都屯在家里了
Y*G
10 楼
这里似乎是正解
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jl
... a single write to a non-volatile long or double value is treated as two
separate writes: one to each 32-bit half. This can result in a situation
where a thread sees the first 32 bits of a 64-bit value from one write, and
the second 32 bits from another write.
>>> Writes and reads of volatile long and double values are always atomic. <
<<
所以,对于volatile成员的读写一定是原子操作。
非volatile成员,除了long和double,也是原子操作
【在 Y**G 的大作中提到】
: are you sure?
: http://fuseyism.com/classpath/doc/java/util/concurrent/atomic/A
: JDK code does not use synchronize keywork in set method:
: 77: /**
: 78: * Sets to the given value.
: 79: *
: 80: * @param newValue the new value
: 81: */
: 82: public final void set(long newValue) {
: 83: value = newValue;
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jl
... a single write to a non-volatile long or double value is treated as two
separate writes: one to each 32-bit half. This can result in a situation
where a thread sees the first 32 bits of a 64-bit value from one write, and
the second 32 bits from another write.
>>> Writes and reads of volatile long and double values are always atomic. <
<<
所以,对于volatile成员的读写一定是原子操作。
非volatile成员,除了long和double,也是原子操作
【在 Y**G 的大作中提到】
: are you sure?
: http://fuseyism.com/classpath/doc/java/util/concurrent/atomic/A
: JDK code does not use synchronize keywork in set method:
: 77: /**
: 78: * Sets to the given value.
: 79: *
: 80: * @param newValue the new value
: 81: */
: 82: public final void set(long newValue) {
: 83: value = newValue;
w*z
12 楼
As you quoted in the 5楼, "value" is defined as volatile, that makes
it atomic.
As goodbug pointed out in the earlier post, it's probably easier just to use
AtomicXXX if possible rather than messing up with volatile.
【在 Y**G 的大作中提到】
: are you sure?
: http://fuseyism.com/classpath/doc/java/util/concurrent/atomic/A
: JDK code does not use synchronize keywork in set method:
: 77: /**
: 78: * Sets to the given value.
: 79: *
: 80: * @param newValue the new value
: 81: */
: 82: public final void set(long newValue) {
: 83: value = newValue;
it atomic.
As goodbug pointed out in the earlier post, it's probably easier just to use
AtomicXXX if possible rather than messing up with volatile.
【在 Y**G 的大作中提到】
: are you sure?
: http://fuseyism.com/classpath/doc/java/util/concurrent/atomic/A
: JDK code does not use synchronize keywork in set method:
: 77: /**
: 78: * Sets to the given value.
: 79: *
: 80: * @param newValue the new value
: 81: */
: 82: public final void set(long newValue) {
: 83: value = newValue;
p*y
13 楼
那我都弄etsy卖去
l*n
14 楼
Here I post the an example from thinking in java:
If you blindly apply the idea of atomicity, you see that getValue( ) in the
following program fits the description:
//: concurrency/AtomicityTest.java
import java.util.concurrent.*;
public class AtomicityTest implements Runnable {
private int i = 0;
public int getValue() { return i; }
private synchronized void evenIncrement() { i++; i++; }
public void run() {
while(true)
evenIncrement();
}
public static void main(String[] args) {
ExecutorService exec = Executors.newCachedThreadPool();
AtomicityTest at = new AtomicityTest();
exec.execute(at);
while(true) {
int val = at.getValue();
if(val % 2 != 0) {
System.out.println(val);
System.exit(0);
}
}
}
} /* Output: (Sample)
191583767
*///:~
However, the program will find non-even values and terminate. Although
return i is indeed an atomic operation, the lack of synchronization allows
the value to be read while the object is in an unstable intermediate state.
On top of this, since i is also not volatile, there will be visibility
problems. Both getValue( ) and evenIncrement( ) must be synchronized. Only
concurrency experts are qualified to attempt optimizations in situations
like this; again, you should apply Brian’s Rule of Synchronization.
Anyone has some idea of this? the i is int here and evenIncreasement method
is synchronized here. It explains that getValue() is not Atomic process.
If you blindly apply the idea of atomicity, you see that getValue( ) in the
following program fits the description:
//: concurrency/AtomicityTest.java
import java.util.concurrent.*;
public class AtomicityTest implements Runnable {
private int i = 0;
public int getValue() { return i; }
private synchronized void evenIncrement() { i++; i++; }
public void run() {
while(true)
evenIncrement();
}
public static void main(String[] args) {
ExecutorService exec = Executors.newCachedThreadPool();
AtomicityTest at = new AtomicityTest();
exec.execute(at);
while(true) {
int val = at.getValue();
if(val % 2 != 0) {
System.out.println(val);
System.exit(0);
}
}
}
} /* Output: (Sample)
191583767
*///:~
However, the program will find non-even values and terminate. Although
return i is indeed an atomic operation, the lack of synchronization allows
the value to be read while the object is in an unstable intermediate state.
On top of this, since i is also not volatile, there will be visibility
problems. Both getValue( ) and evenIncrement( ) must be synchronized. Only
concurrency experts are qualified to attempt optimizations in situations
like this; again, you should apply Brian’s Rule of Synchronization.
Anyone has some idea of this? the i is int here and evenIncreasement method
is synchronized here. It explains that getValue() is not Atomic process.
w*z
16 楼
you can getValue after the first i++ since getValue is not synchronized.
besides, i is not volatile, the caller thread might never see the new value.
it might read i from processor cache.
the
【在 l******n 的大作中提到】
: Here I post the an example from thinking in java:
: If you blindly apply the idea of atomicity, you see that getValue( ) in the
: following program fits the description:
: //: concurrency/AtomicityTest.java
: import java.util.concurrent.*;
: public class AtomicityTest implements Runnable {
: private int i = 0;
: public int getValue() { return i; }
: private synchronized void evenIncrement() { i++; i++; }
: public void run() {
besides, i is not volatile, the caller thread might never see the new value.
it might read i from processor cache.
the
【在 l******n 的大作中提到】
: Here I post the an example from thinking in java:
: If you blindly apply the idea of atomicity, you see that getValue( ) in the
: following program fits the description:
: //: concurrency/AtomicityTest.java
: import java.util.concurrent.*;
: public class AtomicityTest implements Runnable {
: private int i = 0;
: public int getValue() { return i; }
: private synchronized void evenIncrement() { i++; i++; }
: public void run() {
s*1
24 楼
现在降到1.99M了.. 购买力有这么强大?@[email protected]
p*y
25 楼
如果要在其他地方出手的话,是要加手工费的,所以价格肯定比换版要高,换版就想换
回个材料费好给我继续败
对了,zinga mm,上次你给我建议说把那个绕的briolette下面的小红珠子做长,我照
你说的做了个,是比我原来那个设计好看,谢谢啊
【在 z***a 的大作中提到】
:
: 如果在ebay上,
: 其实MM可以稍微提高一下价格,起码把ebay的fee加进来。
: 我是觉得ebay毕竟用户更多,上华人的特备是换班的,相对比例少一些~
: just my 2 cents, 'cause MM is such a nice person! Really wish you could
: figure out ways to sell!
回个材料费好给我继续败
对了,zinga mm,上次你给我建议说把那个绕的briolette下面的小红珠子做长,我照
你说的做了个,是比我原来那个设计好看,谢谢啊
【在 z***a 的大作中提到】
:
: 如果在ebay上,
: 其实MM可以稍微提高一下价格,起码把ebay的fee加进来。
: 我是觉得ebay毕竟用户更多,上华人的特备是换班的,相对比例少一些~
: just my 2 cents, 'cause MM is such a nice person! Really wish you could
: figure out ways to sell!
p*y
26 楼
你从哪里看到这些数据的啊
我也要看
其实降到1.99M, 是说不定有一大批linsting 刚好end了,但是没几个人list新的,哈
哈,不一定是卖掉了
【在 s*******1 的大作中提到】
: 现在降到1.99M了.. 购买力有这么强大?@[email protected]
我也要看
其实降到1.99M, 是说不定有一大批linsting 刚好end了,但是没几个人list新的,哈
哈,不一定是卖掉了
【在 s*******1 的大作中提到】
: 现在降到1.99M了.. 购买力有这么强大?@[email protected]
v*3
29 楼
我在ETSY上也有店……但是都卖不出去…………真想哭…………TOT
全都是纯手工的捏…………
全都是纯手工的捏…………
相关阅读
为啥这么多老印会Java?Spring project 各位喜欢用maven 还是gradle ?求救:在买火车票的网站,如何改变刷新的频率?How to reverse a String unicode safe侏儒婊子邢慧强半婊子中国海洋大学半婊子保研黑幕 2003年大连理工大学电子系考研失利的青岛二中学生侏儒婊子邢慧强被中国海洋大学电子系破格录取为中国海洋大学电子系的硕士,如果给半婊子中国海洋大学加上一个Java code review跪求大牛指点Java,看不懂什么意思。求问如何学习multithreadingjava如何keep大数组在内存中?HashMap entry lazy initialization in multithreaded enviroment?heap dump 请教请教两个hadoop的简单问题开源是可以看到源代码的意思吧,为什么这个看不到呢?Split a String into valid English words请问hadoop hive调用jni的问题找一个Google Glass的use case,要求牵涉到开发的 (转载)侏儒婊子邢慧强半婊子中国海洋大学半婊子保研黑幕 2003年大连理工大学电子系考研失利的青岛二中学生侏儒婊子邢慧强被中国海洋大学电子系破格录取为中国海洋大学电子系的硕士,如果给半婊子中国海洋大学加上一个问个eclipse装jar的入门问题请教一下怎么学习java framework,怎么找java工作也问个 HashMap问题