Как найти, располагают и проблемы памяти? C#
Ответ мороженого корректен, однако обратите внимание, что, если Вы абсолютно не должны использовать MD5 (например, вызванный на Вас для совместимости), лучшим выбором является SHA1, поскольку MD5 имеет слабые места к долгосрочному использованию.
я должен добавить, что SHA1 также имеет теоретические уязвимости, но не как серьезные. Текущее состояние искусства в хешировании - то, что существует много заменяющих хеш-функций кандидата, но ни один еще не появился в качестве стандартной лучшей практики для замены SHA1. Так, в зависимости от Ваших потребностей Вам было бы целесообразно сделать Ваш хеш-алгоритм настраивающимся, таким образом, он может быть заменен в будущем.
7 ответов
Прочтите по этой ссылке
Стивен Туб очень подробно объясняет различные техники для этого. Ниже приведены некоторые краткие моменты из его статьи
. Добавив финализатор для целей отладки, вы можете представить способ узнать, когда класс не был должным образом удален, если финализатор никогда не вызывается, вы знаете, что disposed не был вызван
Чтобы получить дополнительную информацию об экземпляре, идентификаторах потоков и т. д., чтобы помочь сузить круг в каком экземпляре он не был удален, он создает класс FinalizationDebgger который будет удерживать ваш одноразовый класс, который, в свою очередь, вызовет Dispose of the Экземпляр класса FinalizationDebugger при его удалении. Если Dispose не вызывается ваш экземпляр класса, тогда при запуске Finalizer он вызовет финализатор для Экземпляр FinalizationDebgger, в котором вы можете утверждать или генерировать исключение, чтобы помочь отладить проблема,
Переместите весь связанный с отслеживанием код в базовый класс, который ваш одноразовый класс затем наследовать от, что делает код намного чище. Этот подход может работать или не работать поскольку вы записываете базовый класс и если вы уже наследуете от другой базы.
В последнем варианте все переносится в статический класс, который ваши экземпляры позвонить. FinalizationDebugger становится статическим классом, который предоставляет три статических методы: Constructor, Dispose и Finalizer. Идея в том, что вы называете эти методы из соответствующего места вашего класса (dispose / finalize / constructor). Это минимально вторгается в ваш код, поскольку обычно включает добавление всего трех строк кода. Все из этих методов помечены ConditionalAttribute, поэтому они будут вызываться только вашим классом, когда вы компилируете свой класс в режиме DEBUG.
Стивен также объясняет плюсы и минусы каждого из своих подходов. В решениях представлены различные варианты, и вам нужно будет оценить каждый, чтобы понять, какой из них лучше всего подходит для вашей ситуации. НЕОБХОДИМО прочитать ИМХО
Надеюсь, это поможет.
Также попробуйте ANTS Memory Profiler . Существует 14-дневная полностью функциональная бесплатная пробная версия, и мне очень нравится интерфейс.
Раскрытие информации: прямо сейчас они спонсируют Herding Code, поэтому я попробовал его. Но меня это очень впечатлило - я профилировал приложение 30 часов и получил из него массу полезной информации. Пользовательский интерфейс действительно полезен - он проведет вас через процесс, и он выглядит чертовски чисто.
Ознакомьтесь с .NET Memory Profiler . Существует 15-дневная пробная версия, и она стоит лицензионных сборов.
Легко определять утечки памяти с помощью сбор и сравнение снимков Снимки памяти .NET включают данные о распределении экземпляров .NET и живые экземпляры в то время снимок был собран. Они обеспечивают много полезной информации и сделай это легко идентифицировать потенциальную память утечки, особенно когда два снимка сравниваются.
Расширение ответов JP и Рида.
Я хотел устранить небольшую путаницу. Если вы видите значительное увеличение памяти, проблема вряд ли связана с вызовом Dispose. Dispose обычно используется для освобождения неуправляемых ресурсов, таких как дескрипторы. Они не занимают много памяти, но более ценны как ресурсы.
Увеличение объема памяти обычно связано с большими объектами или коллекциями, доступными из управляемого объекта, имеющего прямой или косвенный корень через объект стека или сильный дескриптор GC. Это та область, на которой вы, вероятно, захотите сосредоточить свое расследование.
Вот метод, который я использую:
http://www.codeproject.com/KB/dotnet/Memory_Leak_Detection.aspx
В проекте кода в настоящее время есть ссылка на приложение, специально предназначенное для поиска не удаленных объектов.
Вы также можете использовать WinDbg и SOS. Они имеют то преимущество, что они бесплатны и очень, очень подробны, хотя к ним немного сложно привыкнуть.
Вот сообщение в блоге , описывающее процесс.