Александр Дроздов, Axiom JDK - Убираем мусор без следов

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Доклады о сборщиках мусора звучат на Java-конференциях уже более 10 лет. За это время наши коллеги успели рассказать и о способах настройки сборщиков мусора, и о технологиях, которые в них реализованы. Однако в настоящее время появились новые проблемы, требующие решения при выборе конфигурации Java. Технологии, которые раньше казались никому не нужными, стали актуальными, появились новые задачи совместимости, а вопрос безопасности вышел на передний план.
Рассматриваем три вопроса, связанные со сборщиками мусора: что делать с безопасностью памяти; что делать со старыми приложениями, работающими на старых JDK и, соответственно, на старых сборщиках мусора - не таких эффективных, как современные; что делать с приложениями, которые работают на Native Image и не используют доступные им ресурсы.
Скачать презентацию с сайта JPoint - jrg.su/TNBW8x

[@user-md3xy2kc5l]

А есть пример реального применения данного вектора атаки? Очень сомнительно выглядит такая защита памяти, если у злоумышленника есть возможность запускать произвольный код на Си на той же машине. Что ему мешает читать всю память, снимать дампы и делать что угодно ещё?

[@ixtal23]

Данный метод гарантирует снижение производительности и не гарантирует отсутствие утечек данных. Есть множество мест, помимо кучи джавы, где эта утечка возможна: многочисленные системные кэши и буферы, оффхип память джавы, память выделяемая нативными методами и тд и тп. Потом есть системный менеджер памяти который может делать с памятью какие угодно оптимизации невидимые jvm. Данная проблема может быть решена только на системном уровне, например тотальным сквозным шифрованием памяти.