Я услышал конфликтующие истории по этой теме, и ищу определенную ясность.
Как можно было бы расположить a string
возразить сразу или по крайней мере очистить трассировки от него?
Это зависит от обстоятельств. Литеральные строки по умолчанию интернированы , поэтому даже если ваше приложение больше не ссылается на них, они не будут собраны, поскольку на них ссылается внутренняя структура интернирования. Другие строки такие же, как и любой другой управляемый объект. Как только на них больше не ссылается ваше приложение, они имеют право на сборку мусора.
Подробнее о стажировке здесь, в этом вопросе: Где находятся строковые литералы Java и .NET?
Все дело в сборщике мусора, который сделает это за вас. Вы можете заставить его запустить очистку, вызвав GC.Collect ()
. Из документации:
Используйте этот метод, чтобы попытаться освободить всю память, которая недоступна.
Все объекты, независимо от того, как долго они находятся в памяти, считаются для сбора; однако объекты , на которые имеются ссылки в управляемом коде , не собираются. Используйте этот метод , чтобы заставить систему попытаться освободить максимальный объем доступной памяти.
Это самое близкое, что я думаю !!
Установите для строковой переменной значение null, если оно вам не нужно.
string s = "dispose me!";
...
...
s = null;
, а затем вызовите GC.Collect ()
, чтобы отменить сборщик мусора, но GC НЕ МОЖЕТ гарантировать, что строка будет немедленно собрана.
Если вам нужно защитить строку и иметь возможность утилизировать ее, когда захотите, используйте System.Security.SecureString
класс.
Защитите конфиденциальные данные с помощью класса SecureString в .NET 2.0
Не существует детерминированного способа удалить все следы строки ( System.String
) из памяти. Единственный вариант - использовать массив символов или объект SecureString
.
Один из лучших способов ограничить время жизни строковых объектов в памяти - объявить их как локальные переменные в самой внутренней возможной области видимости, а не как частные переменные-члены класса.
Младшие разработчики часто ошибочно объявляют свои строки ' private string ...
' в самом классе.
Я также видел, как опытные разработчики из лучших побуждений пытались кэшировать сложную конкатенацию строк (a + b + c + d ...) в частной переменной-члене, чтобы им не приходилось ее вычислять. Большая ошибка - перерасчет практически не занимает времени, временные строки собираются мусором почти сразу, когда происходит первое поколение GC, а память, поглощенная кэшированием всех этих строк, просто забирает доступную память у более важных элементов, таких как кэшированные записи базы данных или кешированный вывод страницы.
Я отвечу на этот вопрос с точки зрения безопасности.
Если вы хотите уничтожить строку по соображениям безопасности, то это, вероятно, связано с тем, что вы не хотите, чтобы кто-либо следил за вашей секретной информацией, и вы ожидаете, что они могут просканировать память или найти ее в файле подкачки или что-то в этом роде, если компьютер украден или взломан иным образом.
Проблема в том, что после создания System.String в управляемом приложении уже мало что можно сделать. Может быть какой-то хитрый способ небезопасного отражения и перезаписи байтов, но я не могу представить, что такие вещи будут надежными.
Уловка состоит в том, чтобы вообще никогда не помещать информацию в строку.
Однажды у меня возникла эта проблема с системой, которую я разработал для ноутбуков некоторых компаний. Жесткие диски не были зашифрованы, и я знал, что, если кто-то возьмет ноутбук, он может легко просканировать его в поисках конфиденциальной информации. Я хотел защитить пароль от таких атак.
Я делаю это следующим образом: я помещаю пароль в массив байтов, фиксируя события нажатия клавиш в элементе управления текстовым полем. Текстовое поле никогда не содержало ничего, кроме звездочек и отдельных символов. Пароль никогда не существовал в виде строки. Затем я хешировал массив байтов и обнулял оригинал. Затем хэш подвергался операции XOR со случайным жестко закодированным ключом, который использовался для шифрования всех конфиденциальных данных.
После того, как все было зашифровано, ключ был обнулен.
Естественно, некоторые данные могут существовать в файле подкачки в виде открытого текста, и также возможно, что последний ключ также может быть проверен. Но никто не собирался украсть пароль, черт возьми!