Каков ваш контрольный список разработки для Java-приложений с низкой задержкой?

Question

Я хотел бы создать полный контрольный список для приложения с низкой задержкой Java. Можете ли вы добавить свой контрольный список здесь?

Вот мой список
1. Сделайте ваши объекты неизменными
2. Попробуйте уменьшить синхронизированный метод
3. Порядок блокировки должен быть хорошо задокументирован и тщательно обработан.
4. Используйте профилировщик
5. Используйте закон Амдала и найдите последовательный путь исполнения
6. Используйте утилиты параллелизма Java 5 и заблокируйте их.
7. Избегайте приоритетов потоков, поскольку они зависят от платформы.
8. Разогрев JVM можно использовать
9. Предпочитаю несправедливую стратегию блокировки
10. Избегайте переключения контекста (многие потоки приводят к непродуктивной работе)
11. Избегайте бокса, распаковки
12. Обратите внимание на предупреждения компилятора
13. Количество нитей должно быть равно или меньше количества сердечников.

Приложение с низкой задержкой настраивается на каждые миллисекунды.

Answer 1

Хотя неизменность хороша, она не обязательно улучшит задержку. Обеспечение низкой задержки может зависеть от платформы.

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

Answer 2

избегайте упаковки / распаковки, по возможности используйте примитивные переменные.

Answer 3

Избегайте обширной блокировки и многопоточности, чтобы не нарушать расширенные функции современных процессоров (и их кешей). Затем вы можете использовать один поток до невероятных пределов (6 миллионов транзакций в секунду) с очень низкой задержкой.

Если вы хотите увидеть реальное Java-приложение с малой задержкой и достаточным количеством сведений о его архитектуре, взгляните на LMAX:

Архитектура LMAX

Answer 4

Избегайте переключения контекста, где это возможно, на пути обработки сообщений Следствие: использовать NIO и поток с единичными событиями (реактор)

Answer 5

Покупайте, читайте и понимайте Эффективная Java . Также доступно онлайн

Answer 6

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

Answer 7

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

Answer 8

В дополнение к уже разработанным решениям уровня разработчика также может быть очень полезно рассмотреть ускоренные среды выполнения JIT, например, решения Zing и памяти без кучи, такие как Teracotta BigMemory и Apache Ignite, для сокращения остановок GC Stop-the-world. Если какой-то графический интерфейс использует бинарные протоколы, такие как Hessian, ZERO-C ICE вместо веб-сервиса и т. Д. Очень эффективен.

Answer 9

Я думаю, что «Использовать изменяемые объекты только там, где это уместно» лучше, чем «Сделать ваши объекты неизменяемыми».Многие приложения с очень низкой задержкой имеют пулы объектов, которые они повторно используют для минимизации GC.Неизменяемые объекты не могут быть использованы таким образом.Например, если у вас есть класс Location:

class Location {
    double lat;
    double lon;
}

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

Этот подход намного сложнее, чем использование неизменяемого объекта определения местоположения, поэтому его следует использовать только там, где это необходимо.

Answer 10

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

Как сказал Кнут, «преждевременная оптимизация - корень всего зла».