• 🔥 Бесплатный курс от Академии Кодебай: «Анализ защищенности веб-приложений»

    🛡 Научитесь находить и использовать уязвимости веб-приложений.
    🧠 Изучите SQLi, XSS, CSRF, IDOR и другие типовые атаки на практике.
    🧪 Погрузитесь в реальные лаборатории и взломайте свой первый сайт!
    🚀 Подходит новичкам — никаких сложных предварительных знаний не требуется.

    Доступ открыт прямо сейчас Записаться бесплатно

Ошибки "Локальная куча переполнена" или "Пространство кучи Java"

  • Автор темы Автор темы Vadim
  • Дата начала Дата начала
Всё чистится. Абсолютно весь код пробит такими конструкциями:
как нить поставь туда принты (будешь неприятно удивлён) ;) на клиенте (на серваке не смотрел) может быть с большим "запаздыванием" этот блок, а если в классах есть потоки (например в либах) - до него ваще может не дойти (вернее дойдёт, но потоки останутся в памяти)
Ваще все много-поточные приложения - это не для контекста домины, даже в "обычной" жвм, экзекаторы могут не дать завершиться программе (при всех join и т.п.)
Как пример - есть бот (телеги) на okhhhp3 клиенте (с лонгполлинг) - при ошибке (критичном исключении) может ещё долго торчать в памяти. Ток SIGTERM (Ctrl-C в интерактиве) процесс прибьёт
в домине возможно что-то с опциями ГЦ (GC - garbage collector) надо крутить...
время жизни всех нотусячих объектов надо сокращать до минимума или вовсе не юзать
ещё ловил ситуацию с объемом памяти (указанным в нотес ини) под жвм в агентах, 2048М вешало клиента (12-го)

лучше вариант - сделать агентов на ЛС с вызовом ЛС2Ж
или вынести (как упоминал выше)

ЗЫЖ в текущей реализации жвм (класслоадера), в агентах, очень убого, и по скорости запуска, кмк, ничем не отличается от вызова внешней жвм, а использование нотусячих классов только усугубляет ситуацию
 
Последнее редактирование:
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab