Могу ли я (и хочу ли я когда-либо) установить максимальный размер кучи в .net?

Question

Исходя из опыта Java, я привык сообщать JVM, каким должен быть максимальный размер кучи.Если работающая программа пытается проглотить больше, чем разрешено, а сборщик мусора не может освободить больше ресурсов, то выдается OutOfMemoryError и все идет наперекосяк.Поэтому установка максимального размера кучи важна в Java.

Применимо ли это к .net? Можете ли вы установить ограничения на размер кучи?Продолжает ли CLR увеличивать свою кучу, пока не достигнет физических пределов машины?Или это не проблема в .net по какой-то тонкой причине, которую мои шоры Java мешают мне видеть?

Answer 1

Вы не можете установить максимальный размер кучи в .Net, если вы сами не размещаете CLR в процессе.

Редактировать:Чтобы контролировать распределение памяти CLR, включая максимальный размер кучи, вам необходимо использовать API хостинга для размещения clr и, в частности, использовать «Интерфейсы диспетчера памяти». Некоторую начальную информацию можно найти здесь. Журнал MSDN, колонка CLR Inside Out:API-интерфейсы хостинга CLR

Редактировать:чтобы ответить на ваш вопрос, почему вы хотите контролировать распределение памяти или, в частности, максимальный размер кучи, вы обычно этого не хотите, но если вы пишете приложение, похожее на SQL Server или IIS, или какое-то приложение реального времени, тогда у вас будет довольно веская причина контролировать память и, в частности, избегать подкачки, иначе сама CLR и операционная система уже работают довольно хорошо работа за вас, и остается только убедиться, что ваше приложение использует минимум ресурсов, чтобы все работало хорошо.

Answer 2

Нет, это не относится к .NET. Куча действительно продолжает расти, пока не может больше расти. (Очевидно, что это «после попытки восстановления памяти через GC, увеличьте кучу».) По сути, в .NET GC не так много настроек, как в Java. Вы можете выбрать серверный GC или клиентский, и я думаю, что есть возможность включить / выключить параллельный GC (я найду ссылки через минуту), но это в основном так.

РЕДАКТИРОВАТЬ: Кажется, есть немного больше, хотя и не так много. Запись в блоге Рика Минериха о настройках GC и следующий , кажется, знает скорее, чем я, по этому поводу. Они, вероятно, являются хорошей отправной точкой для дальнейших исследований, но в основном это флаги, а не ограничения по объему памяти, доступные в JVM.

РЕДАКТИРОВАТЬ: Ответ Попа поднимает хороший вопрос - я предполагаю, что "нормальный" Модель хостинга CLR (т.е. не под вашим контролем). Если вы хотите приложить все усилия, чтобы организовать его самостоятельно, вы, вероятно, получите гораздо больший контроль - за счет дополнительной работы по его размещению. Я не могу сказать, что когда-либо смотрел на эту сторону вещей.

Answer 3

Возможно, вы захотите взглянуть на System.Runtime.MemoryFailPoint .

Answer 4

Насколько я обнаружил, не существует простого способа управляет размером кучи приложения .Net с помощью CLR.

Ссылка выше только половина отвечает на вопрос. Когда я исследовал эту же проблему, ответ был "Куча растет, чтобы использовать всю доступную память" как будто это единственная причина, по которой вы хотите контролировать максимальный размер кучи.

На серверных средах (обычно Java) вы не хотите, чтобы приложение с плохим поведением загружало память за счет других размещенных приложений. Простое решение - ограничить объем памяти, который приложение может использовать для своей кучи. Это достигается с помощью аргумента Java -Xmx, так что вы можете гарантировать, что приложение не будет использовать больше, чем запланировано, например. -Xmx256M. Поскольку выделение памяти в куче во время инициализации может замедлить запуск приложений, Java использует аргумент -Xms, чтобы позволить приложениям, которые много создают объекты во время инициализации, начинать с большого блока кучи вместо того, чтобы JVM постоянно изменяла размер кучи по мере идет.

. CLR .Net не имеет этой возможности. Я подозреваю, что это потому, что .Net CLR не является виртуальной машиной. CLR - это API (я бы добавил, достаточно всеобъемлющий), который служит адаптером для собственных .dll, что приравнивается к подходу, гораздо более похожему на исполняемый файл, когда дело доходит до управления памятью.

Я задал этот вопрос о разработке SharePoint и слышал, что возможно было бы возможно контролировать размер кучи с помощью модулей IIS, называемых веб-приложениями, с помощью которых вы можете указать IIS ограничить память определенного веб-приложения. Интересно, так ли это, потому что IIS имеет настроенные подпрограммы, которые заменяют / переопределяют new () / malloc () / etc и, таким образом, могут предоставлять этот тип управления клиентским приложениям. Это означает, что автономным приложениям .Net не повезло, если вы не хотите написать собственный менеджер памяти на C ++ и создать интерфейс для .Net