現在、ウェブスパイダーやファイル検索システムのように見えるアルゴリズムがあります。処理する要素のコレクションがあり、要素を処理すると、より多くの要素がキューに入れられる可能性があります。
ただし、このアルゴリズムはシングル スレッドです。これは、db からデータをフェッチし、一度に 1 つの db 接続のみを使用したいためです。私の現在の状況では、パフォーマンスは重要ではありません。これは、デバッグを容易にするための視覚化の目的でのみ行っています。
私にとって、キューの抽象化を使用するのは自然なことのように思えますが、キューを使用することはマルチスレッド化を意味するようです - 私が理解しているように、標準的な Java キューの実装のほとんどは java.util.concurrent パッケージにあります。
プルとプッシュをサポートする任意のデータ構造を使用できることは理解していますが、この場合、どのデータ構造を使用するのがより自然かを知りたいです (シングル スレッド アプリケーションでキューを使用しても問題ありませんか?)。
基本的にjava.util.concurrentは、単一のスレッドで構造体を使用しても問題ありません。
注意すべき主なことは、通話のブロックです。のような制限付きサイズの構造体を使用し、満杯のキューでメソッドArrayBlockingQueueを呼び出すとput、呼び出し元のスレッドは、キューにスペースができるまでブロックされます。何らかの種類のキューを使用しtake、それが空のときに呼び出すと、呼び出し元のスレッドは、キューに何かが入るまでブロックされます。アプリケーションがシングルスレッドの場合、これらのことは決して起こらないため、永久にブロックされます。
ブロックを回避putするには、 のような無制限の構造を使用できますLinkedBlockingQueue。削除時のブロックを回避するには、非ブロック操作を使用します。removeキューが空の場合は例外をスローし、pollnull を返します。
そうは言っても、 にQueueないインターフェースの実装がありますjava.util.concurrent。ArrayDequeおそらく良い選択でしょう。
Queue は java.util で定義されています。LinkedList は Queue であり、同時実行にはあまり適していません。Queue メソッドはブロックしないため、シングル スレッドの観点からは安全です。
シングル スレッド アプリケーションでは任意のキューを使用できます。同時スレッドがない場合の同期オーバーヘッドは無視できるはずであり、要素の処理時間が非常に短い場合にのみ顕著になります。
ThreadPool で Queue を使用する場合は、両方を組み合わせたExecutorServiceを使用することをお勧めします。ExecutorService はデフォルトで LinkedBlockingQueue を使用します。
http://tutorials.jenkov.com/java-util-concurrent/executorservice.html
http://recursor.blogspot.co.uk/2007/03/mini-executorservice-future-how-to-for.html
http://www.vogella.com/articles/JavaConcurrency/article.html