Каков Ваш контрольный список разработки для приложения низкой задержки Java?
Я хотел бы создать всесторонний контрольный список для Java низкое приложение задержки. Можно ли добавить контрольный список здесь?
Вот мой список
1. Сделайте свои объекты неизменными
2. Попытайтесь уменьшить синхронизированный метод
3. Блокировка порядка должна быть хорошо зарегистрирована и обработана тщательно
4. Используйте профилировщика
5. Используйте закон Amdhal и найдите последовательный путь выполнения
6. Используйте утилиты Java 5 параллелизма и блокировки
7. Избегайте приоритетов Потока, поскольку они - зависимый платформы
8. Прогрев JVM может использоваться
9. Предпочтите несправедливую стратегию блокировки
10. Избегайте контекстного переключения (много выводов потоков для противостояния продуктивный)
11. Постарайтесь не упаковывать, распаковывать
12. Обратите внимание на предупреждения компилятора
13. Количество потоков должно быть равным или меньшим, чем количество ядра
Приложение низкой задержки настраивается для каждого миллисекунды.
6 ответов
Используйте StringBuilder вместо String при генерации больших строк. Например запросы.
Избегайте упаковки / распаковки, по возможности используйте примитивные переменные.
Купите, прочтите и поймите Эффективная Java . Также доступен в Интернете
Хотя неизменяемость - это хорошо, она не обязательно улучшит задержку. Обеспечение низкой задержки, вероятно, будет зависеть от платформы.
Помимо общей производительности, настройка сборщика мусора очень важна. Уменьшение использования памяти поможет GC. В частности, если вы можете уменьшить количество предметов среднего возраста, которые необходимо перемещать, оставьте их либо долгоживущими, либо недолговечными. Также избегайте любых прикосновений к перманентному генератору.
Еще одна важная идея - сначала заставить его работать, затем измерить производительность, затем изолировать все узкие места, затем оптимизировать их, а затем снова измерить, чтобы убедиться в улучшении.
Как сказал Кнут, «преждевременная оптимизация - корень всех зол».
По возможности избегайте переключения контекста на пути обработки сообщений. Следствие: используйте NIO и единственный поток цикла событий (реактор)