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

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

class Location {
    double lat;
    double lon;
}

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

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

Ответ 11

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