- 主题:请教板上大佬，常见的memory leak通常发生在什么情况呢
--
FROM 60.180.32.*
一般而言，在带gc的语言上，需要先明确定义“内存泄露”
【 在 ustcBoy (ustcBoy) 的大作中提到: 】
--
FROM 114.86.46.*
生命周期比预期的长，或者说不容易（或是无法）找到对象的引用，但是对象确实被保持着引用。
技术水平低，只能抛出这种水平的砖头。
想听听大佬的见解。
【 在 oldwatch () 的大作中提到: 】
: 一般而言，在带gc的语言上，需要先明确定义“内存泄露”
:
: 【 在 ustcBoy (ustcBoy) 的大作中提到: 】
--
FROM 60.180.32.*
不飞unsafe指针或者直接扒拉堆外内存的话
其实应该整不出内存泄露，业务代码最多是内存浪费
无端增加不必要的内存/gc开销，甚至导致耗尽内存
如果“常规”业务代码导致泄露，某种意义上可以认为是gc实现/基础库的锅
比如弄个引用计数然后掉循环引用坑里之类（不是说C#/java）
【 在 ustcBoy (ustcBoy) 的大作中提到: 】
: 生命周期比预期的长，或者说不容易（或是无法）找到对象的引用，但是对象确实被保持着引用。
: 技术水平低，只能抛出这种水平的砖头。
: 想听听大佬的见解。
: ...................
--
FROM 114.86.46.*
好的，这种定义下的[内存浪费]或许正是我本来想问的[内存泄露]。
它一般常见的出现原因是什么呢？
【 在 oldwatch () 的大作中提到: 】
: 不飞unsafe指针或者直接扒拉堆外内存的话
:
: 其实应该整不出内存泄露，业务代码最多是内存浪费
: 无端增加不必要的内存/gc开销，甚至导致耗尽内存
--
FROM 60.180.32.*
一般情况下是在不知情时，static 引用的对象里面慢慢积累了一大串引用
另一个原因是GC回收了内存不一定会把内存释放回操作系统，资源管理器看起来好像内存一直占用很高，实际上没有泄露
【 在 ustcBoy (ustcBoy) 的大作中提到: 】
: 好的，这种定义下的[内存浪费]或许正是我本来想问的[内存泄露]。
: 它一般常见的出现原因是什么呢？
--
FROM 113.65.10.*
这个总共有十几种情况
【 在 ustcBoy 的大作中提到: 】
--
FROM 183.15.177.*
能简要说一些常见的吗，谢谢了
【 在 letdown () 的大作中提到: 】
: 这个总共有十几种情况
:
: 【 在 ustcBoy 的大作中提到: 】
--
FROM 60.180.32.*
一直往容器里面加元素，忘记在合适的时机删元素。
--
FROM 222.126.245.*