Предварительное создание объектов в отдельном потоке

Question

Предположим, что у меня есть метод Java, как:

public Ouput respond(Input input) { /* .. */ } 

Объект Output имеет много полей, - некоторые из этих полей зависят от Input объекта, а остальные предопределены. Я хочу сделать поток, который вызывает respond(), чтобы вернуться как можно быстрее.

Для этого я хочу, чтобы породить еще один поток, который предварительно-создает Output объект, устанавливает некоторые из полей и помещает их в очередь, так что нить работает respond() может забрать его из очереди, установите остальные поля и возврат Это.

Каков наилучший способ реализовать что-то подобное? Мой прототип использует ограниченный LinkedBlockingQueue, но есть ли лучшие способы реализации этой идеи?

Моя цель - как можно быстрее получить метод respond(), поэтому другие предложения, которые соответствуют этой цели, также приветствуются. :-)

Answer 1

Возможно, вы можете приспособить свою реализацию к тому, что выходные объекты не должны создаваться для каждого вызова reply(), но для повторной обработки объектов Output, когда они больше не нужны. Сброс полей должен быть быстрее, чем создание их с нуля, и если у вас высокая пропускная способность объекта, это также экономит ваше время на сборке мусора, а также улучшает производительность кеша процессора и Java VM.

Конечно, это может работать, только если вы можете контролировать весь процесс и можете изменить вызывающего абонента, который получает результат ответа().

Но если у вас действительно есть такие высокие требования к производительности, это может быть другой идеей для игры. Просто не делайте это слишком сложным, чтобы ремонтироваться больше.

Answer 2

Это звучит как случай, когда вы можете хорошо использовать Future и Executor. Подробнее здесь:

• http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html
• http://java.sun.com/javase/6/docs/api/java/util/concurrent/Executor.html

Вот конкретный пример:

ExecutorService executor = Executors.newSingleThreadExecutor(); 

final Input input = ... 
Future<Output> future = executor.submit(new Callable<Output>() { 
    public Output call() { 
    return respond(input); 
    } 
}); 

// do some work 

Output output = future.get(); // this blocks until it's done 

В вашем случае, так как вы упомянули, что некоторые из полей в Output объекта являются для немедленного использования, в то время как другие используются позднее, вы можете структурировать свой объект Output содержат фьючерсы в качестве полей. Например:

public class Output { 
    private String fieldA; // immediate field 
    private Future<String> fieldB; // delayed field 

    public void setFieldA(String fieldA) { this.fieldA = fieldA; } 
    public String getFieldA() { return fieldA; } 
    public void setFieldB(Future<String> fieldB) { this.fieldB = fieldB; } 
    public Future<String> getFieldB() { return fieldB; } 
} 

Вы бы затем структурировать метод ответа, как это:

public Output respond(final Input input) { 
    Output output = new Output(); 
    String fieldA = ... 
    output.setFieldA(fieldA); 

    Future<String> fieldBFuture = executor.submit(new Callable<String>() { 
    public String call() { 
     String fieldB = ... 
     return fieldB; 
    } 
    } 

    output.setFieldB(fieldBFuture); 
} 

И использовать Output объект:

Input input = ... 
Output output = respond(input); 

String fieldA = output.getFieldA(); 
// do some work 
String fieldB = output.getFieldB().get(); 

Answer 3

Если остальные поля действительно «заранее определено», почему бы не сделать их статичными в классе Output?

Answer 4

Почему бы не создать фабрику создания объекта, которая в процессе сборки предварительно заполняет внутреннее хранилище объектов Output, доставляет их по запросу и содержит логику, чтобы знать, когда необходимо повторно заполнить внутренний магазин? Возможно, что-то вроде этого (обратите внимание, что это просто простой код, но есть четкие места, где вы можете сделать намного больше, например, иметь определенные алгоритмы, чтобы определить, когда в пуле слишком мало объектов, синхронизировать на заселении и т.д.):

public class OutputFactory { 

    private List<Output> outputPool = new LinkedList<Output>(); 

    public OutputFactory() { 
     this.populatePool(); 
    } 

    private void populatePool() { 
     // spawn a new thread here, if you wish, to optimize time-to-return 
     for (int i = 0; i < 100; i++) { 
      outputPool.add(new Output()); 
     } 
    } 

    public Output getNewOutput() { 
     Output newOutput = outputPool.remove(0); 
     if (outputPool.size() < 10) { 
      populatePool(); 
     } 
     return newOutput; 
    } 

} 

Answer 5

поскольку все потоки обмена ту же кучу, я не могу себе представить, что их создание в другом потоке собирается сделать большую разницу, насколько распределение обеспокоено. Если вы видите выгоду от потоковой передачи, это связано с тем, что любое вычисление требуется для установки предварительно определенных полей объекта Output.

Если это так, вы можете сделать еще лучше иметь один шаблон. Вывод объекта с заранее заданными полями, а затем просто иметь respond() клонировать общий объект шаблона. (Если объект еще не клонирован, и вы не можете этого сделать, это будет стоить примерно так же, чтобы сами копировать поля.)

Если шаблон не работает, но вы можете перерабатывать экземпляры вывода, это, вероятно, еще лучший вариант, поскольку никакой новой памяти вообще не нужно выделять, и предопределенные поля даже не нужно копировать; они уже будут установлены.

Любая из этих стратегий позволит вам ускорить метод respond() без накладных расходов отдельного потока.

Answer 6

Если создание объекта, используемого по полям вывода, довольно дорогое, стоимость использования другого потока будет во много раз больше, чем стоимость установки нескольких полей.