問題タブ [java.util.concurrent]

Boost Thread ライブラリは java.util.concurrent ライブラリと比べてどうですか?

パフォーマンスは非常に重要なので、私は C++ を使い続けることを好みます (最近では Java の方がはるかに高速ですが)。C++ でコーディングする必要があることを考えると、スレッド化を容易にし、エラーを起こしにくくするためにどのようなライブラリが存在しますか?

最近、JDK 1.5 の時点で Java メモリ モデルが変更され、同時実行性の問題が修正されたと聞きました。C++はどうですか？私が最後に C++ でマルチスレッド プログラミングを行ったのは、pthreads を使用した 3 ～ 4 年前のことです。ただし、大規模なプロジェクトにはもう使用したくありません。私が知っている唯一の他の選択肢は、Boost Threads です。しかし、それが良いかどうかはわかりません。java.util.concurrent については良いことを聞いたことがありますが、Boost スレッドについてはまだ何も聞いていません。

ねえSOGuruのimはこのコードで1つの仕事をしています

プログラムを初めて実行しようとすると、このエラーが発生します。

少しゴーグルしたので、これはスレッドで通常発生するエラーのようです。スレッドが同じリソースに同時にアクセスしようとする理由ですが、これが、このシステムでマルチスレッド化をまったく行わない理由です。

誰かがこれが起こっている理由を説明できますか、それを回避するためのハックを考えてください

どうもありがとう^_^

Collections.synchronizedMap()次のコードは、並行性で正確性を維持しながら使用せずに書き直すことができますか？

つまり、代わりに使用できるjava.util.concurrentの何かがありますか？単に置き換えることに注意してください

明らかに機能しません

私はいつもスレッドに戸惑っていましたが、現在、私のクラスではスレッドを多用しています。私たちは java.util.concurrent を使用していますが、基本さえ理解していません。UpDownLatch、先物、実行者; これらの言葉は私の頭の上を飛んでいます。必要なことを一から学ぶのに役立つリソースを提案してもらえますか?

よろしくお願いします！

long次の要件/事実を持つタイプのカウンターが必要です。

• カウンターのインクリメントには、できるだけ時間がかからないようにする必要があります。
• カウンターは1つのスレッドによってのみ書き込まれます。
• カウンターからの読み取りは別のスレッドで行われます。
• カウンターは定期的に（1秒間に数千回も）インクリメントされますが、5秒ごとに1回だけ読み取られます。
• 正確な精度は必須ではありません。カウンターのサイズの大まかなアイデアだけで十分です。
• カウンターがクリアされたり、デクリメントされたりすることはありません。

これらの要件に基づいて、どのようにカウンターを実装することを選択しますか？単純なlongものとして、volatile longまたはを使用してAtomicLong？なんで？

現時点では、私は持ってvolatile longいますが、別のアプローチがより良いかどうか疑問に思っていました。私はまた、++counterとは対照的に行うことによって私の長い時間を増やしていcounter++ます。割り当てが行われていないので、これは本当にもっと効率的ですか（私は他の場所で信じるように導かれています）？

リスト/テーブルのエントリをバックアップするために概念的に使用されるConcurrentLinkedQueueを読み書きするマルチスレッドアプリがあります。私はもともとこれにConcurrentHashMapを使用しましたが、これはうまく機能しました。注文エントリを追跡する必要がある新しい要件があるため、条件によっては、最も古い最初の注文で削除される可能性があります。ConcurrentLinkedQueueは良い選択であるように見え、機能的にはうまく機能します。

設定可能な数のエントリがメモリに保持され、制限に達したときに新しいエントリが提供されると、キューは最も古いものから順に検索され、削除できるエントリが最初に検索されます。特定のエントリはシステムによって削除されず、クライアントとの対話を待ちます。

発生しているように見えるのは、キューの先頭に発生したエントリがあります。たとえば、10万エントリ前です。キューには構成されたエントリの数が制限されているようです（size（）== 100）が、プロファイリング時に、メモリ内に最大100KのConcurrentLinkedQueue$Nodeオブジェクトがあることがわかりました。これは仕様によるもののようで、ConcurrentLinkedQueueのソースを一瞥するだけで、削除すると、保存されているオブジェクトへの参照が削除されるだけで、リンクリストは繰り返しのために残されます。

最後に私の質問：この性質のコレクションを処理するための「より良い」怠惰な方法はありますか？私はConcurrentLinkedQueueの速度が大好きです。この場合、可能と思われる無制限のリークを許容することはできません。そうでない場合は、順序を追跡するために2番目の構造を作成する必要があり、同じ問題に加えて同期の問題が発生する可能性があります。

Android アプリケーションで ConcurrentLinkedQueue を使用したいのですが、コードを記述しましたが、プロジェクトのビルド時にエラーが発生します。

ADT プラグインの最新バージョンで Eclipse を使用しています。

この問題を解決する方法はありますか?

ScheduledThreadPoolExecutor オブジェクトを使用してタスクをスケジュールしています。私は次の方法を使用します。

遅延を 30 秒に設定します (遅延 = 30,000 および単位 = TimeUnit.MILLISECONDS)。タスクがすぐに実行される場合もあれば、70 秒かかる場合もあります。

ScheduledThreadPoolExecutor は CPU 固有のクロックを使用していると思います。System.currentTimeMillis()、System.nanoTime() [CPU 固有] を比較するテストを実行すると、次のように表示されます。

スケジュール: 1272637682651ms、7858346157228410ns

実行: 1272637682667ms、7858386270968425ns

差は 16ms ですが、4011374001ns (または 40,113ms)

40秒の2つのCPUクロックの間に不一致があるように見えます

Java コードでこの問題を解決するにはどうすればよいですか? 残念ながら、これはクライアント マシンであり、システムを変更することはできません。

ユーザーに HashMap を返すアプリケーションを作成しています。ユーザーは、この MAP への参照を取得します。バックエンドでは、マップを更新するいくつかのスレッドを実行します。

私はこれまでに何をしてきましたか？

すべてのバックエンド スレッドを作成したので、共通チャネルを共有して MAP を更新します。したがって、バックエンドでは、同時書き込み操作は問題にならないと確信しています。

私が抱えている問題

1. ユーザーが MAP を更新しようとすると、同時に MAP がバックエンドで更新されます --> 同時書き込み操作の問題。
2. MAP から何かを読み取ろうとすると同時に MAP がバックエンドで更新されている場合 --> 同時 READ および WRITE 操作の問題。

今までそのような問題に直面したことはありませんが、将来直面する可能性があることを恐れています. 提案してください。

私は使っているConcurrentHashMap<String, String>.