本人在一个对象里面注册了个事件，然后当这个对象不再被引用的话是不是 会自动被GC回收，包括对象里的监听事件？
本人不知道是不是需要手动注销事件。就算手动注销事件也没有一个入口可以提供本人去注销事件的呀。请了解的朋友们给个建议吧。谢谢。
本人不知道是不是需要手动注销事件。就算手动注销事件也没有一个入口可以提供本人去注销事件的呀。请了解的朋友们给个建议吧。谢谢。
解决方案
1
+= 是事件绑定。 -= 就是取消事件绑定。
本人建议你析构函数里或其他关闭函数里调用取消事件绑定，原因是本人之前碰到过诡异的事件，你不取消绑定有可能会调用这个事件。
本人建议你析构函数里或其他关闭函数里调用取消事件绑定，原因是本人之前碰到过诡异的事件，你不取消绑定有可能会调用这个事件。
1
一般不用特意去注销（反正本人没注销过），注册是+=，注销就是-=
10
事件是依赖倒置机制，也就是说，对象 A 的事件被 B 对象监听，此时 A 并不依赖于 B，相反地B依赖于 A。A将消息通知给B，但是A并不依赖B，相反地事件触发类型定义了事件接口（而不是事件接收方来定义接口）。
对于 GC 来说，只要B依赖于A 则需要先释放A，但是A并没有依赖所以可以释放。
假设作为服务的 A 对象并不释放，但是你希望能够让 GC 去释放那个看起来是客户对象的 B，那么你就需要“注销事件”，否则就会原因是事件的倒置依赖关系而产生内存泄漏。
对于 GC 来说，只要B依赖于A 则需要先释放A，但是A并没有依赖所以可以释放。
假设作为服务的 A 对象并不释放，但是你希望能够让 GC 去释放那个看起来是客户对象的 B，那么你就需要“注销事件”，否则就会原因是事件的倒置依赖关系而产生内存泄漏。
5
假如被监听的对象存在，这个监听的对象是不会回收的
假如需要个入口的话就是在你移除该对象的时候
假如需要个入口的话就是在你移除该对象的时候
1
事件造成的内存泄漏比较容易忽视，即使是纠结于概念，也并不容易想当然地就避免。而所谓的一些“弱引用事件”的做法显然有比较大的性能损失。
所以最好的办法是“埋桩”测试。当你销毁一个对象（不管是简单组件，还是复杂容器组件）之前，可以使用你的测试程序的一个“弱引用”来引用它，然后当它理论上失去联系（几秒钟后应该自动被 GC销毁）之后，1分钟之后查看此弱引用，来判断所引用的对象能否真的已经不存在了。弱引用应该用于测试程序设计，而不是用在实际生产程序中。
所以最好的办法是“埋桩”测试。当你销毁一个对象（不管是简单组件，还是复杂容器组件）之前，可以使用你的测试程序的一个“弱引用”来引用它，然后当它理论上失去联系（几秒钟后应该自动被 GC销毁）之后，1分钟之后查看此弱引用，来判断所引用的对象能否真的已经不存在了。弱引用应该用于测试程序设计，而不是用在实际生产程序中。
1
理论好讲，但是知道 What 的人往往并不能知道 How，讲理论经常都是言行不一的。
所以你需要亲自写测试，特别是最好能用在日常的开发中（你的100个测试用例中总应该有2、3个专门针对内存泄漏进行测试的），本人亲自写出测试来，你才能说本人真的有谱了。
所以你需要亲自写测试，特别是最好能用在日常的开发中（你的100个测试用例中总应该有2、3个专门针对内存泄漏进行测试的），本人亲自写出测试来，你才能说本人真的有谱了。
1
本人再强调一遍，本人看到你的问题的提问方式，只知道求人、照抄，让你设计一个机制来判断“假如不手动注销，会不会产生什么问题”可能你就脑筋懒得动一动了。
抄点代码容易，但是本人亲自动手写测试来“否定之否定”地测验它，这才是真正的技术。会建立一个东西之前，你也要会破坏、毁掉一个东西。假如只会照抄书上的，那么就成了中小学生的思维习惯了，而不是成年人了。
抄点代码容易，但是本人亲自动手写测试来“否定之否定”地测验它，这才是真正的技术。会建立一个东西之前，你也要会破坏、毁掉一个东西。假如只会照抄书上的，那么就成了中小学生的思维习惯了，而不是成年人了。