Я собираюсь утверждать, что это не такая большая проблема, как вы думаете.
Чтобы убедиться, что мы описываем одно и то же: полная коллекция требует, чтобы JVM прошла по графу объектов, чтобы идентифицировать каждый достижимый объект; те, что остались, - мусор. При этом он будет касаться каждой страницы в куче приложения, что приведет к попаданию каждой страницы в память, если она была выгружена.
Я думаю, что это не является проблемой по нескольким причинам: во-первых, потому что современные JVM используют сборщики поколений, и большинство объектов никогда не выходят из молодых поколений, которые почти гарантированно будут в резидентном наборе.
Во-вторых, потому что объекты, которые выходят из молодого поколения, все еще имеют тенденцию часто посещаться, что снова означает, что они должны быть в резидентском множестве. Это более сомнительный аргумент, и на самом деле существует множество случаев, когда долгоживущие объекты не будут затронуты, кроме как с помощью GC (одна из причин, по которой я не верю в кэши с ограниченной памятью).
Третья причина (а может быть и больше) состоит в том, что JVM (по крайней мере, Sun JVM) использует компактный коллектор с меткой-развертки. Таким образом, после GC активные объекты в куче занимают меньшее количество страниц, снова увеличивая RSS. Между прочим, это является основным драйвером для приложений Swing для явного вызова System.gc (), когда они свернуты: сжимая кучу, меньше поменяться местами, когда они снова максимизируются.
Кроме того, следует признать, что фрагментация кучи объектов C / C ++ может стать экстремальной, и молодые объекты будут разбросаны среди более старых, поэтому RSS должен быть больше.