Фрагментация "кучи" для больших объектов

Если формат является распознаваемым как Ваше приложение, почему Вы не определили код, который генерирует этот формат строки? Если существует несколько возможностей, попытайтесь добавить уникальные данные для выяснения, какой путь выполнения кода является преступником.

То, что массивы чередованы с большими освобожденными объектами, приводит меня предполагать, что они были первоначально соединены или по крайней мере связаны. Попытайтесь определить освобожденные объекты выяснить то, что генерировало их и связанные строки.

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

Править: Проигнорируйте регион памяти и определенный размер массива в настоящий момент: просто фигура, что делается с этими строками для порождения утечки. Попробуйте! GCRoot, когда Ваша программа создала или управляла этими строками просто несколько раз, когда существует меньше объектов проследить.

При чтении описаний того, как GC работает, и часть о том, как долговечные объекты заканчиваются в поколении 2, и набор объектов LOH происходит в полном наборе только - как делает набор поколения 2, идея, которая приходит на ум, состоит... в том, почему не только сохраняют поколение 2 и большие объекты в той же "куче", как они собираются быть собранными вместе?

Если это - то, что на самом деле происходит затем, это объяснило бы, как маленькие объекты оказываются в том же месте как LOH - если они достаточно долговечны для окончания в поколении 2.

И таким образом, Вашей проблемой, казалось бы, было бы довольно хорошее опровержение к идее, которая происходит со мной - это привело бы к фрагментации LOH.

Сводка: Ваша проблема могла быть объяснена LOH и поколением 2, совместно использующим тот же регион "кучи", хотя это ни в коем случае не доказательство, что это - объяснение.

Обновление: вывод !dumpheap -stat в значительной степени удары эта теория из воды! Поколение 2 и LOH имеют их собственные регионы.

Отличный вопрос, я узнал, читая вопросы.

Я думаю, что другие биты пути десериализационного кода также используют большую кучу объекта, следовательно, фрагментацию. Если все строки были интернированы одновременно, я думаю, что вы были бы в порядке.

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

Я бы больше смотрел на хранение хэш-таблица последних нескольких строк, которые вы видели и повторно использовали их. Ограничивая размер хеш-таблица и передаю размер, когда вы создаете таблицу, вы можете остановить большую фрагментацию. Затем вам нужен способ удалить строки, которые вы недавно не видели с хеш-таблица, чтобы ограничить его размер. Но если строки, основанные на тему десериализационного кода, в любом случае, вы не получите многое, если ничего.

Вот несколько способов определить точное стек вызовов из LOH выделения.

И чтобы избежать фрагментации LOH, предварительно выделите большой массив объектов и закрепите их. При необходимости используйте эти объекты повторно. Вот сообщение о фрагментации LOH. Что-то вроде этого могло бы помочь избежать фрагментации LOH.