编译器的优化我不是很懂，但是如果那些优化是普通人所难以理解的，而程序员的意图也不是编译器能够完全理解的，那么这样的优化会给可靠性带来麻烦。至少我相信，编译器再怎么智能也无法从代码中完全推测程序员的意图。
如果在java中，我一直持有一个指向垃圾的引用，那么gc该不该回收它？gc能像程序员一样理解程序吗？或者比程序员更好的理解程序？如果不能很好的理解程序和程序开发的意图，那么这样的优化靠得住吗？


如果我发现某些资源需要延后释放，那么大可以用内存池之类的机制来做。可是如果我发现原先交给gc挂历的某些资源需要更及时的释放，我该怎么办呢？之前我对资源的生命期不是很了解（因为使用gc，或者因此使用gc），那么现在我能做什么呢？如果我了解一个东西，那么我能改进它。如果我不了解，那就什么都做不了了。

我说的确定性并不是说静态稳定性，并不是说要一成不变的东西才算高确定性。确定性是指真对于程序员的确定性。所以对于智能指针，一方面它的释放时间有未知性，但是另一方面，程序员对它的释放时机还是能有所掌握的，毕竟当没有人使用它时它一定会被销毁。可是gc呢？如果不手动发起collect而交给gc，程序员对它的释放时机就很难把握。
还是之前的话，技术应该帮助程序员更好的理解和把握自己的程序，而不是反过来让程序员越来越难以把握自己写的程序。if、for、while这些结构帮助程序员更好地组织代码运行流程，从而让程序员更容易理解程序；而有些技术则恰恰相反，有点杀鸡取卵的味道。