Можете ли вы поверить, что все еще есть люди, делающие невежественные сообщения о мусоре (сборщик мусора?) И производительность JVM.
… я снова вернусь к написанию C, так что мне не нужно беспокоиться о производительности …
*вздох*
JVM постоянно совершенствует свои алгоритмы коллектора, и с каждым выпуском в состав компилятора включаются очень сложные оптимизации (и делают это в течение последних 10 лет). Вы * действительно * ожидаете иметь опыт, способность и время для написания лучшего и более оптимизированного кода на C, чем некоторые из самых умных людей на земле?
Pleeeeease …
Если вы похожи на меня и на 99,99% остальных, разумно забыть о С. Просто смирись с этим. (Салют всем хардкорным программистам C, не чувствуйте себя спровоцированным).
Как бы нам, разработчикам не нравились абстракции, мы не можем отрицать тот факт, что они по своей природе утечки . Оборудование * имеет значение *. Тенденция подсчета процессоров и увеличения объема памяти значительно усложняет параллелизм потоков в совместно используемой памяти. Блокировка , переключение контекста и планирование потоков могут сделать вашу пропускную способность равной сиропу, полагая, что вливание большего количества потоков в вашу новую супер-мощную машину каким-то волшебным образом увеличит производительность. Возможно, в какой-то степени, но это не моя точка зрения.
Так что делать? Я не претендую на звание эксперта по производительности, но у меня есть несколько практических советов, которые, по крайней мере, помогли мне устранить некоторые неприятные ошибки производительности в прошлом.
1. Напишите чистый и «тупой» код. Подумайте о том, чтобы сделать ваши классы неизменяемыми, они являются поточно-ориентированными, поэтому не нуждаются в синхронизации и могут кэшироваться с уверенностью, что значения объектов не изменятся после создания. Неизменность также приводит к коду, который легче понять. Не пытайтесь перехитрить JVM с преждевременными приемами оптимизации.
Дональд Кнут сказал: «Программисты тратят огромное количество времени на размышления или беспокойство по поводу скорости некритических частей своих программ, и эти попытки повышения эффективности действительно оказывают сильное негативное влияние при рассмотрении вопросов отладки и обслуживания. Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация — корень всего зла. Однако мы не должны упускать наши возможности в этих критических 3% ».
2. Потратьте некоторое время на понимание того, как работают разные сборщики мусора. Информация немного разбросана, но ее там нет. Найдите место для совместного использования ресурсов между сборкой мусора и вашим приложением. Вообще говоря, большие кучи означают, что сборщик мусора должен работать больше (кража большего количества циклов ЦП), и паузы будут длиннее, но менее частыми. По моему опыту, вы не можете избежать паузы в остановке мира, даже используя CMS, потому что в конечном итоге ваша куча будет фрагментирована как швейцарский сыр, а бум — сбой фрагментации памяти . Хорошая новость заключается в том, что JDK7, вероятно, будет включать в себя новый сборщик с низкой паузой, называемый G1 , который потенциально может полностью избежать пауз «остановка мира». Также см. Сборщик мусора (G1) в Java 7.
3. Всегда используйте java.util.concurrency по умолчанию при программировании. Прочитайте модель памяти Java и спецификацию потоков . Это поможет вам понять, почему ваш код может работать не так, как должен. На тему параллелизма также есть очень хорошие книги:
- Java-параллелизм на практике
- Искусство многопроцессорного программирования
- Параллельное программирование на Java: принципы проектирования и шаблон (2-е издание)
4. Скорее всего, вы имеете дело с унаследованным кодом (на который вы не можете повлиять), который имеет грубую синхронизацию, что вызывает высокую конкуренцию потоков. Использование соответствия процессоров с несколькими процессами JVM на одном компьютере может помочь снизить конкуренцию за «горячие» блокировки.
5. Если вы считаете, что обнаружили проблемы с производительностью JVM, выполнив тесты , сначала убедитесь, что вы знаете, что * знаете *, что ваши измерения точны . Если вы пытаетесь измерить что-то, не измеряйте другие вещи . Игнорирование этого совета может ввести вас в заблуждение, где скрываются реальные проблемы. Поэтому убедитесь, что правильно изолировали части системы перед началом измерений.
Например, если вы подозреваете конфликт потоков, взгляните на ThreadInfo или попробуйте jstat и найдите sun.rt._sync_ContendedLockAttempts.
|
1
|
jstat -J-Djstat.showUnsupported=true -snap PID | grep _sync_ |
Есть так много, чтобы сказать на эту тему, но у меня нет времени, чтобы написать больше прямо сейчас. Удачного кодирования!
Ссылка: Посмотрите, мама, Усэйн Болт от нашего партнера по JCG в блоге Deep Hacks .
Статьи по Теме :