Redian新闻
>
发现 synchronized 的一个问题
avatar
发现 synchronized 的一个问题# Java - 爪哇娇娃
qm
1
java class method 和 instance method 加上 synchronized 关键字后,分别锁住不同
的锁。这样一来,class method 和 instance method 之间就不能用 synchronized 来同
步了(比如访问 static member)。觉得有点不协调,
avatar
xt
2



不要滥用synchronized.

【在 qm 的大作中提到】
: java class method 和 instance method 加上 synchronized 关键字后,分别锁住不同
: 的锁。这样一来,class method 和 instance method 之间就不能用 synchronized 来同
: 步了(比如访问 static member)。觉得有点不协调,

avatar
qm
3
为什么说是“滥用”?莫名其妙。从语言设计角度讲,难道没有问题?java 文档中没有
指出这个问题。




【在 xt 的大作中提到】
:
: 同
: 同
: 不要滥用synchronized.

avatar
xt
4


看你问的语言设计问题我就知道你实在是很naive,就象我第一次写C语言程序老编译不
过赖GNU滥一样.:-)
从语言设计上讲,static synchronized显然是对class本身synchronize,就是说这个
synchronized实际上是global; instance synchronized显然是在instance内部
synchronize.这两个怎么能混在一起?
所以是你的理解不够,不要怪java documentation没有写

【在 qm 的大作中提到】
: 为什么说是“滥用”?莫名其妙。从语言设计角度讲,难道没有问题?java 文档中没有
: 指出这个问题。
:
: 不
: 来

avatar
o*v
5
能不能给个例子?很想了解一下.

【在 xt 的大作中提到】
:
: 有
: 看你问的语言设计问题我就知道你实在是很naive,就象我第一次写C语言程序老编译不
: 过赖GNU滥一样.:-)
: 从语言设计上讲,static synchronized显然是对class本身synchronize,就是说这个
: synchronized实际上是global; instance synchronized显然是在instance内部
: synchronize.这两个怎么能混在一起?
: 所以是你的理解不够,不要怪java documentation没有写

avatar
qm
6
昏。。。



【在 xt 的大作中提到】
:
: 有
: 看你问的语言设计问题我就知道你实在是很naive,就象我第一次写C语言程序老编译不
: 过赖GNU滥一样.:-)
: 从语言设计上讲,static synchronized显然是对class本身synchronize,就是说这个
: synchronized实际上是global; instance synchronized显然是在instance内部
: synchronize.这两个怎么能混在一起?
: 所以是你的理解不够,不要怪java documentation没有写

avatar
m*r
7
xt is correct.
they synchronize on different objects.
instance method sychronizes on instance object.
class method synchronizes on the Class object which represents this class.

【在 qm 的大作中提到】
: 昏。。。
:
: 没

avatar
m*r
8

gcc error message is really confusing for beginners.

【在 xt 的大作中提到】
:
: 有
: 看你问的语言设计问题我就知道你实在是很naive,就象我第一次写C语言程序老编译不
: 过赖GNU滥一样.:-)
: 从语言设计上讲,static synchronized显然是对class本身synchronize,就是说这个
: synchronized实际上是global; instance synchronized显然是在instance内部
: synchronize.这两个怎么能混在一起?
: 所以是你的理解不够,不要怪java documentation没有写

avatar
qm
9
of course, he's correct. but that's not what i was asking for.
another example, to pass a reference parameter in c#, you call
f(ref value);
in c++, you don't have such thing -- even if the parameter is a reference
type, you just call 'f(value)'.
do you think the 'ref' here is extra or perhaps those c# designers are naive?
this is very similar to my question. it's more about the language design, not
what it is. i was asking for your opinions because no one (including java
documentation) mentions

【在 m****r 的大作中提到】
: xt is correct.
: they synchronize on different objects.
: instance method sychronizes on instance object.
: class method synchronizes on the Class object which represents this class.

avatar
c*t
10
ffdt. Of course it is not a design flaw. In fact, it would be a design
flaw if they do the way you said :)
Synchronization on class variables/functions (static ones), are really
things synchronizing "global" things of all instances of the objects.
For example, you can write an id counter to count how many instances
have been created and give an unique id to each instance.
For each instance, they have synchronized functions that, for example,
change the state of the object per se, such adding/d

【在 qm 的大作中提到】
: of course, he's correct. but that's not what i was asking for.
: another example, to pass a reference parameter in c#, you call
: f(ref value);
: in c++, you don't have such thing -- even if the parameter is a reference
: type, you just call 'f(value)'.
: do you think the 'ref' here is extra or perhaps those c# designers are naive?
: this is very similar to my question. it's more about the language design, not
: what it is. i was asking for your opinions because no one (including java
: documentation) mentions

avatar
qm
11
but you still don't understand what i mean.
the problem is not to understand how to use these locks. the problem is that
it's not intuitive. it could be misleading.
all methods are labeled 'synchronized', but this doesn't guarantee
synchronization when they try to access the static data members.
in c++, it's the same to pass a reference parameter and value parameter. you
cannot tell the difference without looking at the prototype. this is a design
flaw. for example, f(value) could be either by r

【在 c*****t 的大作中提到】
: ffdt. Of course it is not a design flaw. In fact, it would be a design
: flaw if they do the way you said :)
: Synchronization on class variables/functions (static ones), are really
: things synchronizing "global" things of all instances of the objects.
: For example, you can write an id counter to count how many instances
: have been created and give an unique id to each instance.
: For each instance, they have synchronized functions that, for example,
: change the state of the object per se, such adding/d

avatar
c*t
12
Sigh, get some more experience before you talk some more non-sense.
There is no confusion between static variables and instance variables.
One is static and one is not. For static variable, use static
synchronizers. For instance variable, use non-static synchronizers.
Don't check function prototype? What are you talking about? All
functions need to be used with their assumptions in mind. An object
is passed by reference/value doesn't mean things inside won't be
changed.
As for C#'s param pa

【在 qm 的大作中提到】
: but you still don't understand what i mean.
: the problem is not to understand how to use these locks. the problem is that
: it's not intuitive. it could be misleading.
: all methods are labeled 'synchronized', but this doesn't guarantee
: synchronization when they try to access the static data members.
: in c++, it's the same to pass a reference parameter and value parameter. you
: cannot tell the difference without looking at the prototype. this is a design
: flaw. for example, f(value) could be either by r

avatar
R*t
13
just out of curiosity, coconut, does Java community complain a lot about this?
When they have to wrap multiple return values into an object or an array just
so that they can return them from one function call, they must have been mad
and complained a lot.

【在 c*****t 的大作中提到】
: Sigh, get some more experience before you talk some more non-sense.
: There is no confusion between static variables and instance variables.
: One is static and one is not. For static variable, use static
: synchronizers. For instance variable, use non-static synchronizers.
: Don't check function prototype? What are you talking about? All
: functions need to be used with their assumptions in mind. An object
: is passed by reference/value doesn't mean things inside won't be
: changed.
: As for C#'s param pa

avatar
r*n
14
If you always need to return multiple values, you are writing code in a
procedural way.
and a symptom you can find with this is that you usually have very long
methods.

this?
just
that
you
design
when you
ref/out.

【在 R*********t 的大作中提到】
: just out of curiosity, coconut, does Java community complain a lot about this?
: When they have to wrap multiple return values into an object or an array just
: so that they can return them from one function call, they must have been mad
: and complained a lot.

avatar
m*t
15

If you are returning multiple values from one method, yet you are
*not* thinking they should be encapsulated in one class, well, rethink.

【在 R*********t 的大作中提到】
: just out of curiosity, coconut, does Java community complain a lot about this?
: When they have to wrap multiple return values into an object or an array just
: so that they can return them from one function call, they must have been mad
: and complained a lot.

avatar
m*t
16

Not sure which java documentation you checked, as far as I can see,
the behavior is clearly described in 8.4.3.6, Java Language Specification,
Second Edition.

【在 qm 的大作中提到】
: but you still don't understand what i mean.
: the problem is not to understand how to use these locks. the problem is that
: it's not intuitive. it could be misleading.
: all methods are labeled 'synchronized', but this doesn't guarantee
: synchronization when they try to access the static data members.
: in c++, it's the same to pass a reference parameter and value parameter. you
: cannot tell the difference without looking at the prototype. this is a design
: flaw. for example, f(value) could be either by r

avatar
m*t
17

I don't understand how this can be misleading - you can always tell
right away by whether there is a 'static' modifier on the same method.
How hard can that be?
well try and distinguish between "methods" and "static methods".

【在 qm 的大作中提到】
: but you still don't understand what i mean.
: the problem is not to understand how to use these locks. the problem is that
: it's not intuitive. it could be misleading.
: all methods are labeled 'synchronized', but this doesn't guarantee
: synchronization when they try to access the static data members.
: in c++, it's the same to pass a reference parameter and value parameter. you
: cannot tell the difference without looking at the prototype. this is a design
: flaw. for example, f(value) could be either by r

avatar
l*s
18
in the coming Java 5.0, you should never use synchronized again.
the new javax.util.concurrent package is very cool.
avatar
qm
19
you still don't understand what i mean. i didn't misunderstand the parameter
passing. i am talking about the syntax surgar. the extra 'ref' keyword in the
function call with reference parameter is very important.
in c#, when you read some source code like this,
f(ref value);
you know the varaible 'value' could be changed by function 'f'. but there's no
such 'syntax surgar' allows a c++ programmer to specify this.
in c++, when you read this,
f(value);
you have to check the header file to make sur

【在 c*****t 的大作中提到】
: Sigh, get some more experience before you talk some more non-sense.
: There is no confusion between static variables and instance variables.
: One is static and one is not. For static variable, use static
: synchronizers. For instance variable, use non-static synchronizers.
: Don't check function prototype? What are you talking about? All
: functions need to be used with their assumptions in mind. An object
: is passed by reference/value doesn't mean things inside won't be
: changed.
: As for C#'s param pa

avatar
qm
20
no, i'm not talking about the definition. what i'm saying is,
even if all methods are 'synchronized', they're still not completely
synchronized. to synchronize access to static data member, the instance method
must do something like this,
class Synchronized {
synchronized void f () {
...
synchronized ( Class.ForName("Synchronized") ) {
// acess static data member
}
// or, call synchronized static method
// to guarantee synchronization,
// you must *not* access static data membe

【在 m******t 的大作中提到】
:
: I don't understand how this can be misleading - you can always tell
: right away by whether there is a 'static' modifier on the same method.
: How hard can that be?
: well try and distinguish between "methods" and "static methods".

avatar
qm
21
not from the place you call the method.

that

【在 m******t 的大作中提到】
:
: I don't understand how this can be misleading - you can always tell
: right away by whether there is a 'static' modifier on the same method.
: How hard can that be?
: well try and distinguish between "methods" and "static methods".

avatar
xt
22

Let's not talk C++ here. I think I have forgotten all I know. :-)
Your understanding of static synchronized is very interesting.

【在 qm 的大作中提到】
: not from the place you call the method.
:
: that

avatar
xt
23

method
Again, the code above is very interesting! :-)
So why don't you use sth like "static synchronized void f()"?
Also your synchronized( Class.forName...) is very funny.
Since you are already in class "Sinchronized", why do you
want to go through a complete dynamic symbol lookup for
the class? Just say synchronized( Synchronized.class) and it
is done. Of course I am not insane enough to synchronize my
variables to a class object so far.

【在 qm 的大作中提到】
: no, i'm not talking about the definition. what i'm saying is,
: even if all methods are 'synchronized', they're still not completely
: synchronized. to synchronize access to static data member, the instance method
: must do something like this,
: class Synchronized {
: synchronized void f () {
: ...
: synchronized ( Class.ForName("Synchronized") ) {
: // acess static data member
: }

avatar
xt
24

I am lost. hehe

【在 qm 的大作中提到】
: not from the place you call the method.
:
: that

avatar
m*t
25

OK, would you agree that whether access to a static member should
be synchronized is orthogonal to whether this access happens in
some instance method from the same class? In other words, if
access to a static member needs to be synchronized, it needs to be
synchronized regardless the access is made by an instance method
or by some code from somewhere else.
If you are suggesting that a "synchronized" modifier on an instance
method should also apply to this class's class object, I think while
it

【在 qm 的大作中提到】
: no, i'm not talking about the definition. what i'm saying is,
: even if all methods are 'synchronized', they're still not completely
: synchronized. to synchronize access to static data member, the instance method
: must do something like this,
: class Synchronized {
: synchronized void f () {
: ...
: synchronized ( Class.ForName("Synchronized") ) {
: // acess static data member
: }

avatar
m*t
26

I suppose wherever you are calling a method you'd actually
know the signature of the method first? 8-)

【在 qm 的大作中提到】
: not from the place you call the method.
:
: that

avatar
m*t
27

BTW, I'd just use getClass() above. 8-)

【在 qm 的大作中提到】
: not from the place you call the method.
:
: that

avatar
qm
28
while reading through your replies, i was lost occassionally what i was really
concerned. so there was one post (not from the place called) that didn't make
much sense (i was thinking about the c#/c++ example).
from language design perspective, the language syntax better to be 'perfect'.
if you know how it works, of course, you know how to avoid potential problems.
what i'm talking about is not how to get around this problem.
the problem is implicit use of lock. although it's neat to use 'synchr

【在 l**s 的大作中提到】
: in the coming Java 5.0, you should never use synchronized again.
: the new javax.util.concurrent package is very cool.

avatar
qm
29
i copied it from 8.4.3.6.

method

【在 m******t 的大作中提到】
:
: BTW, I'd just use getClass() above. 8-)

avatar
qm
30
stupid, c# use lock, not synchronized.

really
make
'perfect'.
problems.
'synchronized'

【在 qm 的大作中提到】
: while reading through your replies, i was lost occassionally what i was really
: concerned. so there was one post (not from the place called) that didn't make
: much sense (i was thinking about the c#/c++ example).
: from language design perspective, the language syntax better to be 'perfect'.
: if you know how it works, of course, you know how to avoid potential problems.
: what i'm talking about is not how to get around this problem.
: the problem is implicit use of lock. although it's neat to use 'synchr

avatar
qm
31
hum, c# does not use 'lock' as method modifier like java.

weak.

【在 qm 的大作中提到】
: stupid, c# use lock, not synchronized.
:
: really
: make
: 'perfect'.
: problems.
: 'synchronized'

avatar
qm
32
plus, c# lock doesn't allow implicit lock.
lock ( expression ) { }
the expression is required. in java, it's optional.
synchronized { } // legal
this is interesting.

【在 qm 的大作中提到】
: hum, c# does not use 'lock' as method modifier like java.
:
: weak.

avatar
xt
33

More stupid, don't you think lock is synchronized?
You can easily write a lock with synchronized methods.
Simply because you don't know does not mean it is
hard.

【在 qm 的大作中提到】
: stupid, c# use lock, not synchronized.
:
: really
: make
: 'perfect'.
: problems.
: 'synchronized'

avatar
xt
34

So what is the point? OK, let me tell you what it means
in java. If you write an instance synchronized method in
java such as
synchronized void foo(){...}, it is the same as
void foo(){
synchronized( this ){...}
}

【在 qm 的大作中提到】
: hum, c# does not use 'lock' as method modifier like java.
:
: weak.

avatar
xt
35

Maybe I am not very much educated in java. I don't know
this! Any way, simply because it has it does not mean you
should use it.
I suggest more java learning for you, before bashing java
using C#. Obviously you only knows very little more than
Hello World in Java.

【在 qm 的大作中提到】
: plus, c# lock doesn't allow implicit lock.
: lock ( expression ) { }
: the expression is required. in java, it's optional.
: synchronized { } // legal
: this is interesting.

avatar
m*t
36
In 8.4.3.6, Class.ForName is used within a static method, which is
the only way to get a class object in a static context. Your example
is different.
I wouldn't exactly call that "copy". 8-)

【在 qm 的大作中提到】
: i copied it from 8.4.3.6.
:
: method

avatar
m*t
37

I don't think this is legal in Java.

【在 qm 的大作中提到】
: plus, c# lock doesn't allow implicit lock.
: lock ( expression ) { }
: the expression is required. in java, it's optional.
: synchronized { } // legal
: this is interesting.

avatar
qm
38
ok, i was wrong. i didn't use much java thread. just want to discuss. let me
correct it: there's not something like
public lock void f () { ... }
in c#.
i would not say i'm bashing java.
people here proudly prefer just 'learning' - another word for 'copying'.

【在 xt 的大作中提到】
:
: Maybe I am not very much educated in java. I don't know
: this! Any way, simply because it has it does not mean you
: should use it.
: I suggest more java learning for you, before bashing java
: using C#. Obviously you only knows very little more than
: Hello World in Java.

avatar
qm
39
should i care?

【在 m******t 的大作中提到】
: In 8.4.3.6, Class.ForName is used within a static method, which is
: the only way to get a class object in a static context. Your example
: is different.
: I wouldn't exactly call that "copy". 8-)

avatar
m*t
40

Uh, that's the only example you gave to support your point. I don't know
if you should care.

【在 qm 的大作中提到】
: should i care?
avatar
m*t
41

Which is probably a good design for C#. I always think having
"synchronized" as part of a method signature discloses too much of the
implementation, whereas the only benefit is the saving of some extra typing.
Well, no offense, but I tend to learn/copy for a while before I would
come out and say XXX is "a design flaw".

【在 qm 的大作中提到】
: ok, i was wrong. i didn't use much java thread. just want to discuss. let me
: correct it: there's not something like
: public lock void f () { ... }
: in c#.
: i would not say i'm bashing java.
: people here proudly prefer just 'learning' - another word for 'copying'.

avatar
qm
42
我说胖子啊,你指出的那个问题并不是我关心的呀,我本来想用 "..." 代替。我是写
C++ 的,不是写 java, C# 的。只是一个偶然的机会接触到这个问题。我只是觉得 java
的这个设计有点问题,想讨论一下,我对程序语言设计有兴趣。麻烦你们不要在不相关的
细节上找麻烦好不好?
我觉得 synchronized static/instance method 可能有那么点问题。我并不能完全肯定
,所以才想问问看。你们说来说去大多是在讲不相关的东西。另外,c# 当中确实没有这
种语法。难道 m$ 抄糊涂给抄漏了?
我很欣赏 c# 的 ref 那个用法。很久以前我就抱怨过 c++ 当中无法分辨值参还是引用。
从这一点可以看出语言设计者是非常细心的。作为程序员你可以说这是一个很小的问题,
你可以不在乎,但是从语言设计角度看就完全不同了。如果你体会不到这一点,那你最多
也就是程序员罢了。就算你会 java,那又怎样?

【在 m******t 的大作中提到】
:
: Which is probably a good design for C#. I always think having
: "synchronized" as part of a method signature discloses too much of the
: implementation, whereas the only benefit is the saving of some extra typing.
: Well, no offense, but I tend to learn/copy for a while before I would
: come out and say XXX is "a design flaw".

avatar
xt
43

java






如果单纯从语言设计上讲,如果C#还不如java那MS就闹笑话了.C#比java晚了好多年啊.
不过讲那么多语言设计没有用,到头来还是programmer.hehe

【在 qm 的大作中提到】
: 我说胖子啊,你指出的那个问题并不是我关心的呀,我本来想用 "..." 代替。我是写
: C++ 的,不是写 java, C# 的。只是一个偶然的机会接触到这个问题。我只是觉得 java
: 的这个设计有点问题,想讨论一下,我对程序语言设计有兴趣。麻烦你们不要在不相关的
: 细节上找麻烦好不好?
: 我觉得 synchronized static/instance method 可能有那么点问题。我并不能完全肯定
: ,所以才想问问看。你们说来说去大多是在讲不相关的东西。另外,c# 当中确实没有这
: 种语法。难道 m$ 抄糊涂给抄漏了?
: 我很欣赏 c# 的 ref 那个用法。很久以前我就抱怨过 c++ 当中无法分辨值参还是引用。
: 从这一点可以看出语言设计者是非常细心的。作为程序员你可以说这是一个很小的问题,
: 你可以不在乎,但是从语言设计角度看就完全不同了。如果你体会不到这一点,那你最多

avatar
qm
44
我倒不觉得这个跟 disclose implementation 有关。否则其他一些关键字/修是字是不是
也是多余的呢?我的看法是,两种几乎一样的 signature 隐性使用了不同的锁(在这样
的上下文中程序员无法指定使用那个锁),在某些情况下容易造成误解。这不是一个好设
计。
不要笑话我对 java 不熟悉,这并不妨碍我考虑这个特定的问题。

me

【在 m******t 的大作中提到】
:
: Which is probably a good design for C#. I always think having
: "synchronized" as part of a method signature discloses too much of the
: implementation, whereas the only benefit is the saving of some extra typing.
: Well, no offense, but I tend to learn/copy for a while before I would
: come out and say XXX is "a design flaw".

avatar
xt
45




就是因为你不熟悉所以才问这种问题啊.如果连使用哪个锁都搞不清还写什么程序?

【在 qm 的大作中提到】
: 我倒不觉得这个跟 disclose implementation 有关。否则其他一些关键字/修是字是不是
: 也是多余的呢?我的看法是,两种几乎一样的 signature 隐性使用了不同的锁(在这样
: 的上下文中程序员无法指定使用那个锁),在某些情况下容易造成误解。这不是一个好设
: 计。
: 不要笑话我对 java 不熟悉,这并不妨碍我考虑这个特定的问题。
:
: me

avatar
m*t
46

^^^^^^^^
This is incorrect. A signature with "static" in it is *completely*
different from one without - regardless you look at it from programming
or language design point of view.
And, no, which lock to use is not 隐性使用, it is explicitly specified
by a "static" modifier, and definitively defined by the language spec.
Java is not something superior to other skills, so nobody is laughing
at you being unfamiliar with the language, however I do not think you
can ha

【在 qm 的大作中提到】
: 我倒不觉得这个跟 disclose implementation 有关。否则其他一些关键字/修是字是不是
: 也是多余的呢?我的看法是,两种几乎一样的 signature 隐性使用了不同的锁(在这样
: 的上下文中程序员无法指定使用那个锁),在某些情况下容易造成误解。这不是一个好设
: 计。
: 不要笑话我对 java 不熟悉,这并不妨碍我考虑这个特定的问题。
:
: me

avatar
m*t
47

Look closer. I don't think "ref" is provided as a convenience -
they *had to* have it in order to support pass-by-reference, otherwise
C# would be pass-by-value only, like java, which isn't necessarily
a bad thing.

【在 qm 的大作中提到】
: 我倒不觉得这个跟 disclose implementation 有关。否则其他一些关键字/修是字是不是
: 也是多余的呢?我的看法是,两种几乎一样的 signature 隐性使用了不同的锁(在这样
: 的上下文中程序员无法指定使用那个锁),在某些情况下容易造成误解。这不是一个好设
: 计。
: 不要笑话我对 java 不熟悉,这并不妨碍我考虑这个特定的问题。
:
: me

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