- 主题:请教板上大佬，常见的memory leak通常发生在什么情况呢
--
FROM 60.180.32.*
生命周期比预期的长，或者说不容易（或是无法）找到对象的引用，但是对象确实被保持着引用。
技术水平低，只能抛出这种水平的砖头。
想听听大佬的见解。
【 在 oldwatch () 的大作中提到: 】
: 一般而言，在带gc的语言上，需要先明确定义“内存泄露”
:
: 【 在 ustcBoy (ustcBoy) 的大作中提到: 】
--
FROM 60.180.32.*
好的，这种定义下的[内存浪费]或许正是我本来想问的[内存泄露]。
它一般常见的出现原因是什么呢？
【 在 oldwatch () 的大作中提到: 】
: 不飞unsafe指针或者直接扒拉堆外内存的话
:
: 其实应该整不出内存泄露，业务代码最多是内存浪费
: 无端增加不必要的内存/gc开销，甚至导致耗尽内存
--
FROM 60.180.32.*
能简要说一些常见的吗，谢谢了
【 在 letdown () 的大作中提到: 】
: 这个总共有十几种情况
:
: 【 在 ustcBoy 的大作中提到: 】
--
FROM 60.180.32.*
长见识了。
lambda导致的泄露可以举个例子吗 ？平时还是比较经常用到lambda表达式的
【 在 letdown () 的大作中提到: 】
: 非托管内存泄漏
: 1.io
: 2.端口瞬间开太多
:
--
FROM 112.12.138.*
我在上面gist写的那个例子就是event的leak . listener class在自身引用变量超出生命周期后仍然无法被GC，被事件发起者的事件指针一直引用着。
【 在 oldwatch () 的大作中提到: 】
: event handler导致内存泄露是啥情形？
:
: 【 在 letdown (不知道我是谁) 的大作中提到: 】
--
FROM 112.12.138.*
是不是要看具体应用场景呢？ 如果是桌面应用中，主窗口一直存活的情况下，错误的保持了对一些服务或者VM的事件引用导致它们无法被GC回收的话，应该会有影响吧？
我没有具体碰到这样的问题，只是纯脑补。请有经验的大佬分享一下体会。
【 在 leadu () 的大作中提到: 】
: eventhandler这些不算泄露，c#也没有循环引用问题
: 但跨环境（非托管，xamarin）容易出一些问题。
:
: 内存泄露不是问题，内存泄露导致的稳定性问题才是问题。程序跑一年泄露1kB的这种一般都不修
--
FROM 60.180.33.*
学习了一下SO说的这个例子，感觉它是指这个lamba 局部变量将会是一个静态的存在，所以无法被GC了，但是Test这个类应该还是在GC的管辖内的。所以即使多次创建的Test也只会有一个lambda成员作为静态存在，而多次创建的Test对象最终都会被回收。这应该不用被视作leak吧？
不知道我理解的对不对。
【 在 leadu () 的大作中提到: 】
: eventhandler这些不算泄露，c#也没有循环引用问题
: 但跨环境（非托管，xamarin）容易出一些问题。
:
: 内存泄露不是问题，内存泄露导致的稳定性问题才是问题。程序跑一年泄露1kB的这种一般都不修
--
FROM 60.180.33.*
用.net 5仿照SO题主的代码测试了一下,发现在Test类生成的IL里有这么一段
.field public static class [System.Runtime]System.Func`2<object, bool> '<>9__0_0'
这应该是这个lambda被自动生成的field成员吧, 看这个类的类型的话,感觉不能算作Leak吧.
【 在 ustcBoy 的大作中提到: 】
: 学习了一下SO说的这个例子，感觉它是指这个lamba 局部变量将会是一个静态的存在，所以无法被GC了，但是Test这个类应该还是在GC的管辖内的。所以即使多次创建的Test也只会有一个lambda成员作为静态存在，而多次创建的Test对象最终都会被回收。这应该不用被视作leak吧？
: 不知道我理解的对不对。
--
FROM 60.180.33.*