引用:
|
作者: sjinny 如果在java中，我一直持有一个指向垃圾的引用，那么gc该不该回收它？gc能像程序员一样理解程序吗？或者比程序员更好的理解程序？如果不能很好的理解程序和程序开发的意图，那么这样的优化靠得住吗？ |
GC不用猜，他就是不回收。编译优化只作他确定与原来程序语义完全等价的步骤。比如ajoo说的，如果一个局部变量你new完没有传出去变量的生存期就结束了，那么编译器就直接把它做成一个stack变量就是一种优化。
至于为什么有些优化程序员会算不清楚，因为优化过的代码非常难懂，但寄存器布局最优计算用的指令最少。
引用:
|
作者: sjinny 可是如果我发现原先交给gc挂历的某些资源需要更及时的释放，我该怎么办呢？ |
call System.GC.Collect()
各种资源之间是不同的，你要让GC来管理那些本应该你自己管的东西就不对了。
引用:
|
作者: sjinny 所以对于智能指针，一方面它的释放时间有未知性，但是另一方面，程序员对它的释放时机还是能有所掌握的，毕竟当没有人使用它时它一定会被销毁。 |
心理问题……其实你上面那句话看出来，用不用gc其实都不知道它什么时候释放内存。所以其实区别不大。可能你这里函数退出的时候就有一个dtor然后连带了好多好多dtor释放智能指针, 结果卡一下。这和gc突然介入相比感觉上也好不到哪里去。
如果你这里关心的是对象的销毁，那么用智能指针也不是一个好的选择。原因如上，你还是不知道它什么时候销毁。可能你不小心引入了一个循环引用，或者不小心多copy了一份。那么就没人帮得了你了。你甚至很难知道这个多出来的引用在哪里。对于这种类型的东西，用using这种scope管理，或者来一个pool集中管理，到时候把pool销毁等，都比用智能指针“确定”得多。如果你觉得pool销毁了内存还没回收，你也可以在那里写一个GC.Collect(). 虽然我觉得大多数情况下并不必要。GC比你清楚内存还剩多少。
引用:
|
作者: sjinny 还是之前的话，技术应该帮助程序员更好的理解和把握自己的程序，而不是反过来让程序员越来越难以把握自己写的程序。if、for、while这些结构帮助程序员更好地组织代码运行流程，从而让程序员更容易理解程序；而有些技术则恰恰相反，有点杀鸡取卵的味道。 |
隐藏细节恰恰帮助程序员更好地把握程序。GC就把和内存相关一些细节隐藏在了你背后。如果这些细节恰巧对你来说不重要，那么GC就大大帮助你集中注意搞设计。就像高级语言把寄存器布局，CPU流水等等都藏了起来。CPU也没告诉你你的指令可能会被乱序执行（可能有些编译优化器知道，并且会有针对地作优化）。