2

lucene ファイルのインデックス作成のパフォーマンスを向上させようとしています。このために、ジョブを実行するワーカー「LuceneWorker」を作成しました。

以下のコードでは、「同時」実行が大幅に遅くなります。私はその理由を知っていると思います.LuceneWorkerのさらに別のタスクを実行するためのメモリがほとんどないのは、先物が限界に達したためです.

Q: エグゼキューターに入る「ワーカー」の量を制限する方法はありますか? 言い換えれば、「n」個の先物がある場合 - 続行せず、最初にドキュメントのインデックス作成を許可しますか?

私の直感的なアプローチは、ArrayBlockingQueue を使用してコンシューマー/プロデューサーを構築することです。しかし、私はそれを再設計する前に正しいのだろうか.

        ExecutorService executor = Executors.newFixedThreadPool(cores);
        List<Future<List<Document>>> futures = new ArrayList<Future<List<Document>>>(3);
        for (File file : files)
        {
            if (isFileIndexingOK(file))
            {
                System.out.println(file.getName());
                Future<List<Document>> future = executor.submit(new LuceneWorker(file, indexSearcher));
                futures.add(future);
            }
            else
            {
                System.out.println("NOT A VALID FILE FOR INDEXING: "+file.getName());
                continue;   
            }
        } 

        int index=0;
        for (Future<List<Document>> future : futures)
        {
            try{

                List<Document> docs = future.get();

                for(Document doc : docs)
                    writer.addDocument(doc);    


            }catch(Exception exp)
            {
                //exp code comes here.
            }
        }
4

2 に答える 2

1

待機中のジョブの数を制限したい場合は、 のように制限さThreadPoolExecutorれたキューで を使用しますArrayBlockingQueue。RejectedExecutionHandlerまた、送信スレッドがキュー内の容量を待機するように、独自にロールします。unboundedExecutorsを使用するため、そのために便利なメソッドを使用することはできません。newFixedThreadPoolLinkedBlockingQueue

于 2013-02-26T00:01:39.430 に答える
1

標準入力のサイズと LuceneWorker クラスの複雑さによっては、Fork/Join フレームワークを使用して少なくとも部分的にこの問題を解決することを想像できました。JDK 8 のCountedCompleter実装 ( jsr166yに含まれる) を使用すると、I/O 操作で問題が発生することはありませんでした。

于 2013-03-09T11:50:19.450 に答える