Примітка перекладача: бажання перевести замітку з'явилося рано-червневого ранку після прочитання її у напівсонному стані у вагоні метро. Цільова аудиторія: люди, які роблять перші кроки в світі Java і за родом свого основного технічного бекграунду або бажання сильно прагнуть забратися під капот Java і вивчити всі електродинамічні процеси. Впевнений, що для тих, хто прочитає це, буде відправною точкою подорожі у світ налаштування JVM і GC. Попутного вітру! Оригінал статті лежить тут Будучи розробником, ви проводите незліченний годинник за вичищенням багів з Java-додатку та досягненням продуктивності в тих місцях, де потрібно. Під час тестування помічаєте, що програма поступово працює повільніше, і в кінці повністю завалюється або просто демонструє погану продуктивність. Зрештою визнаєте, що відбуваються витоку пам'яті. Garbage collector Java робить все, що може, щоб впоратися з цими витоками. Але є тільки багато речей, які можна виконати, коли стикаєтесь із ситуаціями подібними до цих. Вам потрібні способи ідентифікації викликів витоків пам'яті, виявлення причин та розуміння ролі Java garbage collector'а, що впливає на загальну продуктивність програми.
Основні симптоми витоків пам'яті Java
Зустрічаються кілька симптомів, що вказують, що програма має проблеми витоку пам'яті. Невелике зниження продуктивності, а не раптова відмова роботи програми, вказує лише на витік пам'яті. Проблема може траплятися щоразу під час роботи або тільки тоді, коли програма починає працювати з великим обсягом даних або, навпаки, ви починаєте масштабувати програму. Програма, можливо, покаже помилку нестачі пам'яті, як тільки витік зжере всі доступні ресурси пам'яті. Перезапустивши програму та сподіваючись на краще, натрапите неодноразово на аварійні завершення до того моменту, поки витік не буде усунений. Загалом, витоку пам'яті трапляються, коли посилання на об'єкти накопичуються, замість того, щоб звільняти пам'ять. Вони займають всю доступну пам'ять і унеможливлюють додаток доступ до необхідних йому ресурсів.
Помилки конфігурації виглядають як витік пам'яті
Перед тим, як зазирнете в ситуації, що викликають проблеми з пам'яттю Java і проведете аналіз, необхідно переконатися, що дослідження не стосуються абсолютно іншого завдання. Частина помилок out-of-memory виникають через різні помилки, наприклад помилки конфігурації. Програма, можливо, нестача пам'яті в купі або вона конфліктує в системі з іншими додатками. Якщо починаєте говорити про проблеми нестачі пам'яті, але не можете визначити, що викликає витік, погляньте на програму по-іншому. Виявиться, що потрібно зробити зміни в потоці фіналізації або збільшити обсяг permanente generation простору, що є областю пам'яті JVM для зберігання описів класів Java та деяких додаткових даних.
Переваги інструментів моніторингу пам'яті
Інструменти моніторингу пам'яті дають більшу видимість використання доступних ресурсів програмою Java. Використовуючи це програмне забезпечення, ви робите крок для звуження пошуку кореня проблеми витоку пам'яті та інших інцидентів, пов'язаних з продуктивністю. Інструменти йдуть в декількох категоріях, і вам, можливо, потрібно використовувати безліч програм, щоб розібратися як почати правильно позначати проблему і що пішло не так, навіть якщо ви маєте справу з витоком пам'яті. Heap dump (дампа купи) файли дають необхідну інформацію для аналізу Java-пам'яті. У цьому випадку вам потрібно використовувати два інструменти: один для створення дамп-файлу і інший для детального аналізу. Таке рішення дає детальну інформацію про те, що відбувається із додатком. Один раз інструмент вказує місця можливих проблем та працює над звуженням площі, щоб знайти точне місце виникнення інциденту. І цей період часу - час найдовшої і псує настрій частини спроб і помилок. Аналізатор пам'яті вказує кілька проблем у коді, але ви не впевнені абсолютно, з якими проблемами зіткнувся ваш додаток. Якщо все ще стикаєтеся з попередньою помилкою, почніть спочатку і попрацюйте над іншою можливою помилкою. Зробіть одну зміну за один раз і спробуйте продублювати помилку. Потрібно буде дати програмі попрацювати деякий час, щоб продублювати умови виникнення помилки. Якщо при першому тесті відбувається витік пам'яті, не забудьте протестувати програму під навантаженням. Програма може працювати відмінно з невеликою кількістю даних, але може знову викинути попередні помилки при роботі з великим обсягом даних. Якщо ще виникає все та ж помилка, Потрібно почати спочатку і розібрати іншу можливу причину. Інструменти моніторингу пам'яті доводять свою користь після того, як програма стала повністю працюючою. Можна віддалено спостерігати за продуктивністю JVM і проактивним виявленням збійних ситуацій перед тим, як розробник порине в проблему і збиратиме історичні дані продуктивності, щоб допомогти собі в майбутньому покращити техніки програмування та спостерігати як Java працює під важким навантаженням. Багато рішень включають режими оповіщення "небезпека" або інші подібні режими і розробник може знати, що відбувається не так, як хотілося. Кожен розробник не хоче, щоб критична програма, будучи в промексплуатації, падала і була причиною втрати десятків або сотень тисяч доларів під час простою програми, тому інструменти моніторингу пам'яті зменшують час реагування розробника. Додатки моніторингу пам'яті дають почати процес діагностики миттєво, замість того, щоб попросити вас піти до замовника, де ніхто не скаже, яка саме помилка трапилася, або який код помилки видало додаток. Якщо часто занурюєтеся в проблеми пам'яті та продуктивності вашої програми Java, щільно візьміться за процес тестування. Позначте кожну слабку область у процесі розробки та змініть стратегію тестування. Порадьтеся з колегами та порівняйте свої підходи тестування з існуючими найкращими практиками. Іноді вам потрібно переглянути маленький фрагмент коду і далі забезпечити тривалий вплив на всю програму. замість того, щоб попросити вас піти до замовника, де ніхто не скаже, яка саме помилка трапилася або який код помилки видав додаток. Якщо часто занурюєтеся в проблеми пам'яті та продуктивності вашої програми Java, щільно візьміться за процес тестування. Позначте кожну слабку область у процесі розробки та змініть стратегію тестування. Порадьтеся з колегами та порівняйте свої підходи тестування з існуючими найкращими практиками. Іноді вам потрібно переглянути маленький фрагмент коду і далі забезпечити тривалий вплив на всю програму. замість того, щоб попросити вас піти до замовника, де ніхто не скаже, яка саме помилка трапилася або який код помилки видав додаток. Якщо часто занурюєтеся в проблеми пам'яті та продуктивності вашої програми Java, щільно візьміться за процес тестування. Позначте кожну слабку область у процесі розробки та змініть стратегію тестування. Порадьтеся з колегами та порівняйте свої підходи тестування з існуючими найкращими практиками. Іноді вам потрібно переглянути маленький фрагмент коду і далі забезпечити тривалий вплив на всю програму. Позначте кожну слабку область у процесі розробки та змініть стратегію тестування. Порадьтеся з колегами та порівняйте свої підходи тестування з існуючими найкращими практиками. Іноді вам потрібно переглянути маленький фрагмент коду і далі забезпечити тривалий вплив на всю програму. Позначте кожну слабку область у процесі розробки та змініть стратегію тестування. Порадьтеся з колегами та порівняйте свої підходи тестування з існуючими найкращими практиками. Іноді вам потрібно переглянути маленький фрагмент коду і далі забезпечити тривалий вплив на всю програму.
Роль Garbage Collector на пам'ять Java та витоку пам'яті
Garbage Collector (збирач сміття) у Java відіграє ключову роль у продуктивності програми та використання пам'яті. Він шукає невикористовувані (мертві) об'єкти та видаляє їх. Ці об'єкти більше не пам'ятають, так що ваш додаток продовжує забезпечувати доступність ресурсів. Іноді програма не дає GC достатньо часу або ресурсів для видалення мертвих об'єктів і вони накопичуються. Можна зіткнутися з такою ситуацією, коли йде активне звернення до об'єктів, які, ви вважаєте, мертві. Складальник сміття неспроможна зробити нічого з цим, т.к. його механізм автоматизованого управління пам'яті оминає активні об'єкти. Зазвичай збирач сміття працює автономно, але необхідно налаштувати його поведінку на реагування тяжких проблем із пам'яттю. Однак GC може сам призводити до проблем продуктивності.
Області GC
Складальник сміття для оптимізації збирання поділяє об'єкти на різні області. У Young Generation представлені об'єкти, які швидко відмирають. Складальник сміття часто працює в цій галузі з того моменту, коли він повинен проводити очищення. Об'єкти, що залишабося живими після досягнення певного періоду, переходять в Old Generation. В області Old Generation об'єкти залишаються довгий час, і вони не видаляються збирачем так часто. Однак, коли збирач працює в області, програма проходить через велику операцію, де збирач дивиться крізь живі об'єкти для очищення сміття. Через війну об'єкти програми перебувають у кінцевої області permanent generation. Зазвичай ці об'єкти включають потрібні метадані JVM. Додаток не генерує багато сміття в Permanent Generation, але потребує збирача для видалення класів коли класи більше не потрібні.
Зв'язок між Garbage Collector та часом відгуку
Складальник сміття, незалежно від пріоритету виконання потоків програми, зупиняє їх, не чекаючи завершення. Таке явище називається подією "Stop the World". Область Young Generation збирача сміття незначно впливає на продуктивність, але проблеми помітні, якщо GC виконує інтенсивне очищення. Зрештою ви опиняєтеся в ситуації, коли мінорне складання сміття Young Generation постійно запущено або Old Generation переходить у неконтрольований стан. У такій ситуації потрібно збалансувати частоту Young Generation із продуктивністю, яка потребує збільшення розміру цієї галузі збирача. Області Permanent Generation та Old Generation збирача сміття значно впливають на продуктивність програми та використання пам'яті. Ця операція major очищення сміття проходить крізь heap, щоб виштовхнути відмерлі об'єкти. Процес триває довше ніж minor збирання та вплив на продуктивність може йти довше. Коли висока інтенсивність очищення та великий розмір області Old Generation, продуктивність усієї програми пов'язує через події "Stop the world". Оптимізація складання сміття вимагає моніторингу як часто програма запущена, впливу на всю продуктивність та способів налаштування параметрів програми для зменшення частоти моніторингу. Можливо потрібно буде ідентифікувати той самий об'єкт, розміщений більше, ніж один раз, причому додатку не потрібно відгороджуватися від розміщення або вам потрібно знайти точки стиснення, що стримують всю систему. Отримання правильного балансу вимагає приділення близької уваги до всього від навантаження на CPU до циклів вашого збирача сміття, особливо якщо Young та Old Generation незбалансовані. Адресація витоків пам'яті та оптимізація складання сміття допомагає збільшити продуктивність Java-програми. Ви буквально жонгулюєте безліччю частин, що рухаються. Але з правильним підходом усунення проблем та інструментами аналізу, спроектованих щоб дати сувору видимість, ви досягнете світла в кінці тунелю. В іншому випадку замучитеся з виникаючими неполадками, пов'язаними з продуктивністю. Ретельне розміщення пам'яті та її моніторинг грають критичну роль Java-додатку. Необхідно повністю взяти в свої руки взаємодію між складанням сміття, видаленням об'єктів і продуктивністю, щоб оптимізувати додаток і уникнути помилок тих, хто упирається в брак пам'яті. Інструменти моніторингу дають залишатися на висоті, щоб виявити можливі проблеми та визначити тенденції утилізації пам'яті так, що ви приймаєте проактивний підхід до виправлення несправностей. Витік пам'яті часто показує неефективність усунення несправностей звичайним шляхом, особливо якщо ви стикаєтеся з неправильними значеннями параметрів конфігурації, але вирішення питань пов'язаних з пам'яттю допомагають швидко уникнути інцидентів, що стоять у вас на шляху. Досконалість налаштування пам'яті Java та GC роблять ваш процес розробки набагато легшим.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ