Строки и сборка "мусора"

Я услышал конфликтующие истории по этой теме, и ищу определенную ясность.

Как можно было бы расположить a string возразить сразу или по крайней мере очистить трассировки от него?

16
задан Kyle Rozendo 11 March 2010 в 20:45
поделиться

7 ответов

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

Подробнее о стажировке здесь, в этом вопросе: Где находятся строковые литералы Java и .NET?

7
ответ дан 30 November 2019 в 21:53
поделиться

Все дело в сборщике мусора, который сделает это за вас. Вы можете заставить его запустить очистку, вызвав GC.Collect () . Из документации:

Используйте этот метод, чтобы попытаться освободить всю память, которая недоступна.

Все объекты, независимо от того, как долго они находятся в памяти, считаются для сбора; однако объекты , на которые имеются ссылки в управляемом коде , не собираются. Используйте этот метод , чтобы заставить систему попытаться освободить максимальный объем доступной памяти.

Это самое близкое, что я думаю !!

2
ответ дан 30 November 2019 в 21:53
поделиться

Установите для строковой переменной значение null, если оно вам не нужно.

string s = "dispose me!";
...
...
s = null;

, а затем вызовите GC.Collect () , чтобы отменить сборщик мусора, но GC НЕ МОЖЕТ гарантировать, что строка будет немедленно собрана.

-3
ответ дан 30 November 2019 в 21:53
поделиться

Если вам нужно защитить строку и иметь возможность утилизировать ее, когда захотите, используйте System.Security.SecureString класс.

Защитите конфиденциальные данные с помощью класса SecureString в .NET 2.0

7
ответ дан 30 November 2019 в 21:53
поделиться

Не существует детерминированного способа удалить все следы строки ( System.String ) из памяти. Единственный вариант - использовать массив символов или объект SecureString .

2
ответ дан 30 November 2019 в 21:53
поделиться

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

Младшие разработчики часто ошибочно объявляют свои строки ' private string ... ' в самом классе.

Я также видел, как опытные разработчики из лучших побуждений пытались кэшировать сложную конкатенацию строк (a + b + c + d ...) в частной переменной-члене, чтобы им не приходилось ее вычислять. Большая ошибка - перерасчет практически не занимает времени, временные строки собираются мусором почти сразу, когда происходит первое поколение GC, а память, поглощенная кэшированием всех этих строк, просто забирает доступную память у более важных элементов, таких как кэшированные записи базы данных или кешированный вывод страницы.

1
ответ дан 30 November 2019 в 21:53
поделиться

Я отвечу на этот вопрос с точки зрения безопасности.

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

Проблема в том, что после создания System.String в управляемом приложении уже мало что можно сделать. Может быть какой-то хитрый способ небезопасного отражения и перезаписи байтов, но я не могу представить, что такие вещи будут надежными.

Уловка состоит в том, чтобы вообще никогда не помещать информацию в строку.

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

Я делаю это следующим образом: я помещаю пароль в массив байтов, фиксируя события нажатия клавиш в элементе управления текстовым полем. Текстовое поле никогда не содержало ничего, кроме звездочек и отдельных символов. Пароль никогда не существовал в виде строки. Затем я хешировал массив байтов и обнулял оригинал. Затем хэш подвергался операции XOR со случайным жестко закодированным ключом, который использовался для шифрования всех конфиденциальных данных.

После того, как все было зашифровано, ключ был обнулен.

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

2
ответ дан 30 November 2019 в 21:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: