17

すべてのオブジェクトをロック可能にすることは、設計ミスのように見えます。

  1. オブジェクトのごく一部でしか使用しない場合でも、作成されるすべてのオブジェクトに追加のコストがかかります。
  2. ロックの使用は暗黙的になり、lockMap.get(key).lock()任意のオブジェクトの同期よりも読みやすくなりますsynchronize (key) {...}。
  3. 同期されたメソッドは、ユーザーが同期されたメソッドでオブジェクトをロックするという微妙なエラーを引き起こす可能性があります
  4. オブジェクトを 3rd parting API に渡すときに、そのロックが使用されていないことを確認できます。

例えば

class Syncer {
    synchronized void foo(){}
}
...
Syncer s = new Syncer();
synchronize(s) {
    ...
}
// in another thread
s.foo() // oops, waiting for previous section, deadlocks potential
  1. すべてのオブジェクトの名前空間汚染は言うまでもありません (少なくとも C# ではメソッドは静的であり、Java 同期プリミティブでは を使用する必要awaitがあり、オーバーロードする必要はありませんwait... Object)

しかし、このデザインには何らかの理由があると確信しています。固有ロックの大きな利点は何ですか?

4

4 に答える 4

0

実際には、各オブジェクトでそのモニターへの参照しかありません。実際の監視オブジェクトは、同期を使用する場合にのみ作成されます => 失われるメモリはそれほど多くありません。

別の方法は、必要なクラスに手動でモニターを追加することです。これにより、コードが非常に複雑になり、エラーが発生しやすくなります。Java は生産性のためにパフォーマンスを犠牲にしました。

于 2012-08-29T19:08:24.120 に答える
0

synchronized利点の 1 つは、ブロックの終了時に例外によっても自動的にロック解除されることです。

于 2012-08-29T19:08:33.150 に答える
0

I assume that like toString(), the designers thought that the benifits outweighed the costs.

Lots of decisions had to be made and a lot of the concepts were untested (Checked exceptions-ack!) but overall I'm sure it's pretty much free and more useful than an explicit "Lock" object.

Also do you add a "Lock" object to the language or the library? Seems like a language construct, but objects in the library very rarely (if ever?) have special treatment, but treating threading more as a library construct might have slowed things down..

于 2012-08-29T19:11:22.637 に答える