Лучший способ повторно использовать Runnable

Question

У меня есть класс, который реализует Runnable, и в настоящее время я использую Executor в качестве пула потоков для выполнения задач (индексация документов в Lucene).

executor.execute(new LuceneDocIndexer(doc, writer));

Моя проблема в том, что мой класс Runnable создает много объектов Lucene Field, и я предпочел бы повторно использовать их, а затем создавать новые при каждом вызове. Каков наилучший способ повторного использования этих объектов (объекты Field не являются поточно-ориентированными, поэтому я не могу просто сделать их статическими) - мне следует создать свой собственный ThreadFactory? Я заметил, что через некоторое время программа начинает резко ухудшаться, и единственное, о чем я могу думать, - это накладные расходы GC. В настоящее время я пытаюсь профилировать проект, чтобы убедиться, что это даже проблема, но сейчас давайте просто предположим, что это так.

Answer 1

Ваш вопрос спрашивает, как повторно использовать Runnable, поэтому я собираюсь игнорировать другие детали и просто ответить на этот вопрос.

Если вы используете ThreadPoolExecutor, вы можете использовать метод [ThreadPoolExecutor # afterExecute] [1], чтобы вернуть объект Runnable в пул / очередь «кэшированных» Runnables.

[1]: http://java.sun.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#afterExecute(java.lang.Runnable, java.lang.Throwable)

Answer 2

Объект Runnable можно использовать повторно. Это объект потока, которого нет.

Лучший способ? это ваш путь: -)

Я думаю, что это больше вопрос о люцене, чем о готовом вопросе.

Answer 3

Пока я решил просто использовать простую модель Producer-> Consumer. Я передаю BlockingQueue каждому индексатору, а не документу для индексации, и затем главный драйвер программы добавляет новые документы в эту очередь. Индексаторы затем заполняют эту [ограниченную] очередь, повторно используют объекты Field и делятся потокобезопасным IndexWriter.

Я нашел место, где, возможно, не звонил HttpMethod.releaseConnection(), чтобы это могло вызвать проблемы с памятью (неопределенно).

Answer 4

Возможно, вы захотите сделать еще один сравнительный анализ, чтобы определить причины замедления.

Готов поспорить, что ваша проблема не связана с созданием экземпляров Field. У Field нет финализаторов, и они не предназначены для объединения.