• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

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

  • Автор темы Vadim
  • Дата начала

lmike

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

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

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

Обучение наступательной кибербезопасности в игровой форме. Начать игру!