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

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

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

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

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

Покупайте, читайте и понимайте Effective Java. Также доступен в Интернете

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

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

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

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

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

• Рассмотрите возможность использования неблокирующих подходов, а не синхронизации.
• Рассмотрите возможность использования volatile или атомарных переменных вместо блокирующих структур данных и блокировок.
• Рассмотрите возможность использования пулов объектов.
• Используйте массивы вместо списков, так как они более удобны для кэширования.
• Обычно для небольших задач отправка данных на другие ядра может занять больше времени, чем обработка на одном ядре из-за блокировки и задержки доступа к памяти и кэшу. Следовательно, рассмотрите возможность обработки задачи одним потоком.
• Уменьшите частоту обращения к основной памяти и попробуйте работать с данными, хранящимися в кешах.
• Подумайте о выборе JIT-компилятора C2 на стороне сервера, ориентированного на оптимизацию производительности, в отличие от C1, ориентированного на быстрый запуск.
• Убедитесь, что у вас нет ложного совместного использования полей объекта, когда два поля, используемые разными потоками, могут располагаться в одной строке кэша.
• Читать https://mechanical-sympathy.blogspot.com/
• Рассмотрите возможность использования UDP через TCP

Используйте StringBuilder вместо String при создании больших строк. Например запросы.

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

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

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

class Location {
    double lat;
    double lon;
}

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

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

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