揮発性を混合し、読み取りワイトロックとして同期します

StackOverflow https://stackoverflow.com/questions/4289837

質問

多くのスレッドが読み取られ、いくつかのスレッドが書かれたプリミティブタイプ変数を考えてみてください。次のコードは正しく機能しますか？

もしそうなら、それは1より良いパフォーマンスを提供しますか）。すべての方法で同期した宣言。 2）。明示的なreadwritelockを使用していますか？

これは一般的なパターンですか？そうでない場合、この状況では通常どのパターンが使用されますか？

これは現在私にとっては正常に機能しますが、揮発性と同期の両方を使用することは少し冗長だと感じています。

private volatile int value = 1;

public void func1()
{
    if (value == 1) {
        // do something
    }
}

public void func2()
{
    if (value == 2) {
        // do something
    }
}

public void func3()
{
    if (value == 3) {
        // do something
    }
}

public synchronized void increase()
{
    if (value < 10) value++;
}

public synchronized void decrease()
{
    if (value > 0) value--;
}
役に立ちましたか？

解決

多くのスレッドが読み取られ、いくつかのスレッドが書かれたプリミティブタイプ変数を考えてみてください。次のコードは正しく機能しますか？

そう思います。

もしそうなら、それは1より良いパフォーマンスを提供しますか）。すべての方法で同期した宣言。 2）。明示的なreadwritelockを使用していますか？

読み取り操作が書き込みリクエストを上回っていれば、そうだと思います。でも：

  • このカウンターが非常に争われない限り、それはおそらく問題ではありません。それがボトルネックである（またはそうなる）という証拠がない限り、何かを最適化する時間を無駄にしないでください。
  • それが本当にあなたにとって重要であるならば、それをベンチマークしてください。
  • 相対的なパフォーマンスがJVMバージョン /パッチレベル、JVMオプション、ハードウェアに依存している場合でも驚かないでください。たとえば、プロセッサとメモリアーキテクチャの数。

これは一般的なパターンですか？そうでない場合、この状況では通常どのパターンが使用されますか？

これが一般的かどうかはわかりません。しかし、私の直感は、最も一般的なアプローチは、定期的な同期を使用することであり、心配しないことです。非常に競合したデータ構造を扱っていない限り、さまざまなアプローチのパフォーマンスの違いは、全体的なアプリケーションパフォーマンスには重要ではありません。

他のヒント

はい、少なくともある程度は一般的です:)

使用しているパターンは、このIBMの記事で説明されています - > http://www.ibm.com/developerworks/java/library/j-jtp06197/index.html

（パターン＃5、安価な読み取りワイトロックトリック）

ロックがないため、パフォーマンスが向上していると確信していますが、正しいかどうかはコードの意図によって異なります。確かに、動作は同期されたケースとは異なります。動作がロックケースに似ているかどうかは、ロックする場所によって異なります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top