Java Language
Настройка производительности Java

Общий подход

В Интернете собраны советы по повышению производительности программ Java. Возможно, в первую очередь это осознание. Это означает:

• Определите возможные проблемы производительности и узкие места.
• Используйте инструменты для анализа и тестирования.
• Знать хорошие практики и плохие практики.

Первый момент должен быть сделан на этапе проектирования, если говорить о новой системе или модуле. Если говорить о устаревших кодах, то на экране появляются инструменты анализа и тестирования. Самый простой инструмент для анализа производительности JVM - это JVisualVM, который включен в JDK.

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

Уменьшение количества строк

В Java слишком «легко» создать множество экземпляров String, которые не нужны. Это и другие причины могут привести к тому, что ваша программа будет иметь множество строк, которые GC занят очисткой.

Некоторые способы создания экземпляров String:

myString += "foo";

Или, что еще хуже, в цикле или рекурсии:

for (int i = 0; i < N; i++) {
    myString += "foo" + i;
}

Проблема в том, что каждый + создает новую строку (обычно, поскольку новые компиляторы оптимизируют некоторые случаи). Возможную оптимизацию можно выполнить с помощью StringBuilder или StringBuffer :

StringBuffer sb = new StringBuffer(myString);
for (int i = 0; i < N; i++) {
    sb.append("foo").append(i);
}
myString = sb.toString();

Если вы часто строите длинные строки (например, SQL), используйте API-интерфейс String.

Другие вещи, которые необходимо учитывать:

• Уменьшите использование replace , substring и т. Д.
• Избегайте String.toArray() , особенно в часто String.toArray() коде.
• Журнальные отпечатки, которые предназначены для фильтрации (из-за уровня журнала, например), не должны генерироваться (уровень журнала должен быть проверен заранее).
• Используйте библиотеки , как это в случае необходимости.
• StringBuilder лучше, если переменная используется не общим способом (по потокам).

Основанный на доказательствах подход к настройке производительности Java

Дональд Кнут часто цитирует это:

«Программисты тратят огромное количество времени, думая о скорости некритических частей своих программ или беспокоясь о них, и эти попытки эффективности действительно оказывают сильное негативное влияние при отладке и обслуживании. Мы должны забыть о небольшой эффективности, например о 97% времени : преждевременная оптимизация - это корень всего зла, но мы не должны упускать наши возможности в этих критических 3% ».

источник

Принимая во внимание этот совет мудреца, вот рекомендуемая процедура оптимизации программ:

1. Прежде всего, создавайте и кодируйте свою программу или библиотеку с упором на простоту и правильность. Для начала не тратьте много усилий на производительность.

2. Получите его в рабочее состояние и (в идеале) разработайте модульные тесты для ключевых частей кодовой базы.

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

4. Измерьте производительность.

5. Сравните измеренную производительность с вашими критериями того, насколько быстро приложение должно быть. (Избегайте нереалистичных, недостижимых или не поддающихся оценке критериев, таких как «как можно быстрее»).

6. Если вы выполнили критерии, STOP. Вы работаете. (Любые дополнительные усилия, вероятно, пустая трата времени.)

7. Профилируйте приложение во время выполнения вашего теста производительности.

8. Изучите результаты профилирования и выберите самые большие (неоптимизированные) «горячие точки производительности»; т.е. разделы кода, в котором приложение, как представляется, проводит больше всего времени.

9. Проанализируйте секцию кода точки доступа, чтобы попытаться понять, почему это узкое место, и подумайте о том, как сделать это быстрее.

10. Реализуйте это как предлагаемое изменение кода, проверку и отладку.

11. Повторите тест, чтобы узнать, улучшилось ли изменение кода:

    • Если «Да», вернитесь к шагу 4.
    • Если нет, отмените изменение и вернитесь к шагу 9. Если вы не достигли прогресса, выберите другую точку доступа для вашего внимания.

В конце концов вы доберетесь до точки, где приложение либо достаточно быстро, либо вы рассмотрели все важные горячие точки. На этом этапе вам нужно остановить этот подход. Если часть кода потребляет (скажем) 1% от общего времени, то даже 50% -ное улучшение только сделает приложение на 0,5% быстрее в целом.

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

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

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