Содержание
Такие баги коварны: они не приводят к ошибке сразу. Но если приложение активно, баг способен положить всю систему
Инженер Microsoft Мэтт Хэмрик опубликовал разбор ошибки, которая может вызвать утечку памяти, замедление системы и даже крах всей Windows — и все это из-за одной строчки в конфигурационном файле .NET-приложения.
Речь идет о параметре reloadOnChange, который отвечает за автообновление настроек из файла конфигурации.
Проблема возникает, если установить reloadOnChange: true в неподходящем месте — например, в контроллере или middleware-компоненте. В этом случае каждый вызов создает нового «наблюдателя» за файлом, и память начинает стремительно заполняться.
Что делает reloadOnChange
Этот параметр нужен для динамической подгрузки настроек без перезапуска приложения. Но его стоит использовать только при старте и только для нестандартных файлов, которые .NET не мониторит по умолчанию.
Microsoft: 30% кода внутри компании уже написано ИИ. К 2030 это будет 95%tproger.ru
Если включить его не там и не вовремя — приложение начнет плодить объекты, следящие за одним и тем же файлом, и сборщик мусора просто не справится.
По словам Хэмрика, ошибка накапливается медленно, но неотвратимо: система становится все менее отзывчивой, программы начинают сбоить, а в тяжелых случаях падает и сама Windows.
Как Microsoft нашла баг
Хэмрик обнаружил проблему, анализируя дампы памяти .NET, снятые через WinDbg и другие инструменты. Он увидел, как объект конфигурации разрастается в памяти — и каждый экземпляр привязан к новой копии FileSystemWatcher, который отслеживает изменения одного и того же файла.
И хотя пример относится к .NET 7, ошибка не зависит от версии: аналогичная утечка может случиться и в более новых релизах .NET, если допустить такую же архитектурную оплошность.
Почему это важно
Такие баги коварны: они не приводят к ошибке сразу. Но если приложение активно, баг способен положить всю систему — и администратор потратит часы на поиски причины, не подозревая, что виноват всего один флаг в конфиге.
Инженеры Microsoft советуют использовать reloadOnChange осознанно и только там, где это действительно необходимо. Особенно в продакшене.
Разработчики против пользователей
Этот кейс — пример того, как даже маленькая ошибка в коде может превратиться в системную проблему. И это особенно актуально на фоне разговоров о производительности Windows, медленной работе старых устройств и резком росте требований к «железу».
Windows и Linux сравнили в играх. С видеокартами AMD они сопоставимыtproger.ru
Как отмечает сам Хэмрик, часто дело не в слабом компьютере, а в неоптимизированном коде. И если раньше таким ошибкам просто не придавали значения, то сейчас они напрямую сказываются на стабильности всей системы.
