2014-02-04 4 views
0

У меня есть основной вопрос, для которого я не могу найти ответ в сети: Предполагая, что у меня есть приложение, в котором несколько потоков совместно используют один экземпляр утилитного метода, из которого потенциально длинный запускаются длительные расчеты.Java: влияние производительности вызовов с одновременным вызовом по массиву

Возможно ли, что массовые совпадения вызовов методов повлияют на выполнение выполнения методов?

EDIT: «Влияние на производительность» Я имею в виду: Значительное уменьшение скорости выполнения или даже выполнение метода блокировки.

+0

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

+0

@SotiriosDelimanolis Не могли бы вы предоставить ссылку на документацию, где это обсуждается? – achingfingers

+0

У меня нет такой ссылки. Можете ли вы подробнее рассказать о том, что вы подразумеваете под влиянием производительности? –

ответ

1

Если метод не использует ресурс. Тогда Не очень много (по крайней мере, не значительно, вы избежите утверждений). Вы потеряете производительность только в увеличении сбора мусора, использовании ЦП, создания объектов и т. Д., Но потоки Thread и Cache Flushing будут меньше. Из ресурсов я имею в виду общие объекты, общий ввод-вывод. Но на практике, вероятно, у вас будет по крайней мере один общий ресурс.

Но если метод использует некоторые общие ресурсы, то да, этот метод может быть узким местом. Но есть много шаблонов, с помощью которых вы можете улучшить производительность. Например, если многие потоки только читают такой общий ресурс и лишь немногие записывают/обновляют общий ресурс , тогда вы можете использовать ReadWriteLocks для защиты этой блокировки. Или вы можете использовать шаблон актера ->http://www.slideshare.net/drorbr/the-actor-model-towards-better-concurrency

Также всегда старайтесь использовать параллельные структуры данных для совместного использования ваших общих ресурсов. например ConcurrentHashMap может использоваться очень хорошо, чтобы обмениваться информацией между потоками. Для проблем производителей-потребителей среди Threads попробуйте использовать различные реализации BlockingQueue. Эти структуры данных также ухудшают производительность, но в любом случае вы должны платить цену за точность.

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

3

Да, возможно, например, если метод использует общий (или ограниченный) ресурс.

Такой ресурс может быть блокировкой, соединением с базой данных, (медленным) диском или даже оперативной памятью (как объем оперативной памяти, так и доступная пропускная способность памяти ограничены).

+0

Например, соединение с базой данных? – achingfingers

+0

@achingfingers: Например. Или (медленный) диск. Или большой объем памяти. – NPE

+0

Можете добавить один или два ссылки. Тогда мне будет достаточно принять ваш ответ :-) – achingfingers

0

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

Смежные вопросы