@MSGID: 2:5055/182 06555ce3
@PID: jNode ver. 1.5
@TID: jNode ver. 1.5
@CHRS: CP866 2
 [](https://telegra.ph/file/126f1ea1c2cd6ccff4251.jpg)**Самый мощный
инструмент находится между ушами**

 [Весьма часто за утечку памяти принимают то, что ей, вообще говоря,
не является.](https://habr.com/ru/articles/765472/)

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

 К слову, с точки зрения производительности, аллоцировать и
деаллоцировать в цикле - очень фиговая идея, учитывая скорость аллокаторов ОС
общего назначения (и не только общего, к слову).

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

 Причем так и не нашли и побороли посредством рестарт-инжиниринга. Как
обычно, в общем.

 Что я хочу сказать. Как и в тюнинге, одна из самых сложных тут
вещей - диагностика.

 И, разумеется, до плохого можно и не доводить, если просто тщательно
писать код. Ну и, по возможности, не пренебрегать статическим анализом.
http://fido.ortoped.org.ru/photo_2023-10-06_10-00-05.jpg

--- hssergey station
 * Origin: jNode ver. 1.5 (2:5055/182)
SEEN-BY: 301/1 460/58 4500/1 5001/100 5005/49
5015/255 5019/40 5020/715 848
SEEN-BY: 5020/1042 4441 12000 5030/49 1081 5055/182
5058/104 5061/133
SEEN-BY: 5083/444
@PATH: 5055/182 5020/1042 4441