Интересно, как же получить утечку память в менеджед среде, когда

аллокациями управляет гц?%) И когда ты не контроллируешь когда объект задиспоузится

Когда ссылка на объект остаётся же

Это не утечка, у тебя в стринг пуле тоже ссылка остается на строку, утечка?%)

Под "гц" имеется в виду сборщик мусора?

Как это тогда назвать?

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

Есть "технические" утечки, когда память становится недоступна для использования. Чаще всего они ассоциируются с ошибками в коде на си и плюсах (выделение памяти без её освобождения и дальнейшее удаление указателя, или несоответствие способов выделения и освобождения) Есть "логические" утечки. Сохранение памяти, которая не нужна для дальнейшей работы приложения, но которая не может быть освобождена gc из-за наличия на неё ссылок. В js такой тип утечки не только возможен, но и активно практикуется. Этот тип утечек есть во всех распространённых языках с gc: код на жаве и шарпе так же может страдать от утечек, и процессы на них так же могут убиваться oom killer'ом

нет той грани, где повышенный аллокрейт и малое кол-во выделенной памяти хипу, не похож на утечку памяти))

Есть эта грань. Выделение памяти для работы/накопившиеся области памяти, с которыми работы уже не будет Терминология устоявшаяся. Я когда-то тоже считал, что утечки в шарпе это не утечки. Но если прошерстить техническую литературу, то можно найти множество употреблений этого термина по отношению к managed среде. Поэтому твоя война - война с тем, что в комьюнити уже давно определено И вот тебе ещё один кейс: в свифте не gc, а подсчёт ссылок. Циклические ссылки при этом никак не разруливаются. Кажется, даже согласно твоей позиции это утечка. Но ручного управления памятью при этом нет

> с которыми работы уже не будет Так и где та грань, когда будет или нет? Я понимаю что с человеческой точки зрения, можно выделить ее А компьютеру откуда знать об этом? Откуда об этой грани знать гарбадж коллектору?

А зачем нужно знание этой грани кампуктером? Типа если он знает, то это утечка, а если нет, то не утечка? Но я выше написал, что это не так. Термин "утечка памяти" не связан с ручным управлением памятью

Хорошее замечание про гц в свифте, действительно, его там нет, алгоритм с подсчетом ссылок довольно примитивный и не решает проблему с циклическими ссылками, но тут я могу сослаться лишь на то, что такова реализация, и да, в таком случае, так как гц не покрывает такой случай (так как его по факту нет), то может считаться утечкой, Но мы про управляемую нодджс платформу, где с гц таких проблем нет

Они есть, но не в js, а в v8: если ты сохранишь ссылку на substring, то в памяти будет храниться вся строка, даже когда ссылки на эту строку будут потеряны Однако утечки памяти в js есть не по этой причине. А потому, что твоя трактовка этого термина отличается от общепринятой

Есть устоявшиеся терминологии которые приняты сообществом. Вот из официального сайта node.js, из раздела по управлению памятью. ===node.js===== Node.js (JavaScript) is a garbage collected language, so having memory leaks is possible through retainers. As Node.js applications are usually multi-tenant, business critical, and long-running, providing an accessible and efficient way of finding a memory leak is essential. ===node.js===== А вот из доки MDN ===mdn===== There is a limitation when it comes to circular references. In the following example, two objects are created with properties that reference one another, thus creating a cycle. They will go out of scope after the function call has completed. At that point they become unneeded and their allocated memory should be reclaimed. However, the reference-counting algorithm will not consider them reclaimable since each of the two objects has at least one reference pointing to them, resulting in neither of them being marked for garbage collection. Circular references are a common cause of memory leaks. ===mdn======

Собственно, и общее определение никак не противоречит JS

Так если к этим самым объектам нет доступа откуда либо, то какой смысл их оставлять!? P.S. Лучше тогда ссылки оставить, чтобы и примеры сами увидеть.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management

GC не всегда может понять, является объект мусором или нет

Ну это уже больше на правду похоже.