Перевищення накладних лімітів GC

Який час вибірки використовує JVM, щоб перекинути "java.lang.OutOfMemoryError: перевищена гранична межа GC"? Я знаю, що ви можете контролювати 98% та 2% за допомогою параметрів GCTimeLimit та GCHeapFreeLimit, але який час вибірки?

java garbage-collection jvm

— PRK
джерело

Від Java SE 6 HotSpot [tm] Налаштування сміття для віртуальної машини

наступне

Надмірний час GC та OutOfMemoryError

Одночасний збірник викине OutOfMemoryError, якщо на збирання сміття витрачається занадто багато часу: якщо більше 98% всього часу витрачається на збирання сміття і менше 2% купи відбирається, OutOfMemoryError буде викинутий. Ця функція призначена для запобігання застосуванню додатків протягом тривалого періоду часу, не досягаючи незначного прогресу або не вимагаючи його, оскільки купа занадто мала. При необхідності цю функцію можна відключити, додавши в командний рядок опцію -XX: -UseGCOverheadLimit.

Політика така ж, як і в паралельному колекторі, за винятком того, що час, витрачений на виконання одночасних колекцій, не зараховується до граничного обмеження часу 98%. Іншими словами, лише колекції, які виконуються під час зупинки програми, зараховуються до надмірного часу GC. Такі колекції, як правило, обумовлені одночасною помилкою режиму або явним запитом колекції (наприклад, викликом до System.gc ()).

в поєднанні з проходом далі вниз

Одне з найпоширеніших застосувань явного збирання сміття відбувається при розподіленому збиранні сміття (DGC). Програми, що використовують RMI, відносяться до об'єктів інших віртуальних машин. Сміття не можна збирати в цих розповсюджених програмах без періодичного збору локальної купи, тому RMI періодично примушує повні збори. Частоту цих колекцій можна керувати властивостями. Наприклад,
java -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000 вказує явний збір один раз на годину замість стандартної ставки один раз на хвилину. Однак це також може призвести до того, що деякі об'єкти потребуватимуть набагато довшого часу. Ці властивості можна встановити як Long.MAX_VALUE, щоб зробити час між явними колекціями ефективно нескінченним, якщо немає бажання мати верхню межу своєчасності роботи DGC.

Здається, випливає, що період оцінки для визначення 98% становить одну хвилину, але він може бути налаштований на JVM Sun з правильним визначенням.

Звичайно, можливі й інші інтерпретації.

— Едвін Бак
джерело

Розподілений сміттєвий збір RMI - не пов'язаний із регулярним вивезенням сміття. Тож я не бачу, як можна зробити висновок про те, що ти щойно робив.

— Стівен C

Висновок не є ідеальним або навіть правильним, тому "здається, що мається на увазі" використовується замість "мається на увазі". Якщо ви погоджуєтесь із зауваженням, що якщо люди, що перебувають у Sun, використали одну хвилину для визначення інтервалу збирання сміття для RMI, то час збору при одночасному збиранні накопичується лише обчислюється, коли основна програма зупиняється, і зробить трохи стрибка віри , тоді шанси хороші, 98% збирається за одну хвилину. Це чарівне число, але одна хвилина - це чарівне число, яке часто використовується порівняно, наприклад 3,5 хвилини.

— Едвін Бак

@StephenC Ви маєте на увазі, навіть якщо ми встановимо, що -XX:+DisableExplicitGC це не вплине на конфігурацію, пов'язану з RMI, і система викличе gc у частоті, встановленій параметром-Dsun.rmi.dgc.server.gcInterval

— Steephen

@Steephen - Ні. Це не те, що я говорю. Я говорю про це твердження: "Здається, мається на увазі, що період оцінки для визначення 98% триває одну хвилину ..." . І зауважте, що Едвін погоджується, що висновок "недосконалий". Висновок базується на припущенні, що люди, що впроваджували RMI (& DGC), були в тісному спілкуванні з людьми, які впровадили механізм накладних обмежень GC. Я підозрюю, що ці дві події насправді траплялися в різний час. Зауважте, що цей -Dsun.rmi.dgc.server.gcIntervalресурс існує з Java 1.2.

— Стівен С

У будь-якому випадку, кращим підходом до пошуку реальної відповіді на це питання було б ознайомлення з вихідним кодом OpenJDK.

— Стівен С