1.我不愿意对用户做什么假设或者限制，或者至少要尽量减少这种限制。
2.在新游戏的内存要求都达到1g的现在，在很多电脑都需要使用虚拟内存的现在，内存真的嫌多了吗？
3.
代码:
int main()
{
while(true);
return 0;
}
这段代码在机器空闲时会让CPU占用率升到近100%，如果开了很多的线程都在这样使用CPU那会怎么样？OS如何知道这不是用户的意愿而自动调低优先级？毕竟3D渲染之类的应用正常情况就是这样，而另一些应用的正常情况是不应该这样的，OS能自己解决这种问题吗？而很多用户连优先级的意义都搞不清楚。做游戏的时候，入门的代码经常都是这样使用CPU的，之后才会解决控制帧率的问题，才会解决帧与帧之间通过sleep来减少CPU占用。
4.我这么说是因为你前文再拿4G内存来比较，而对于PC上的应用就不能这么比较了。现在还有很多机器用着512M甚至256M的内存。
5.你所说的“统计意义”的统计范围是哪些呢？一个软件类型算一个样本点，还是按照软件数量来算样本点？
6.
悬挂引用：当还有指针指向某块内存时，这块内存就处于“被需要”的状态，这时释放它就会出问题，这是“过早释放”的问题。
内存泄漏：这是“过晚释放”的问题，毕竟现在大多数操作系统都能回收进程的内存资源，所以没多少内存是永远不会回收的，只不过一般回收得太晚而已。
生命期管理，就是在“合适”的时间执行“分配”和“释放”这两个概念所对应的行为。生命期管理机制的责任在确保在“合适”的时间来调用指定的行为，而具体的分配和释放行为由这个机制的使用者来制定。这里的“合适”的时间，就是要使实际的“分配”和“释放”时间尽量紧密地包裹资源的理想生命期。实现了这样的生命期管理机制之后，无论是内存管理还是其他资源管理，其难点在哪？这样的机制是否就是对应着最麻烦的问题？
7.我那个“彻底”针对的是“如果可以彻底解决内存管理问题，就算管理其他资源的时候麻烦一点，也值了。”这句话。我自己没有认为“有技术可以“彻底”解决内存管理问题”。
8.
“如果可以彻底解决内存管理问题，就算管理其他资源的时候麻烦一点，也值了。”
“内存访问违例可以直接让你这个进程完蛋，其他资源访问出错都没有这么猛的效果。至于你说“而如果其他资源的使用有错，那么可能会比内存访问出错的问题更加隐蔽”，你倒是举一个例子出来？什么错误能够比往内存中写数据的时候写到相邻的另外一个对象里去这种错误更隐蔽，更难重现？”
我那些例子针对的是这几句话。特别想说明的就是的确有些非内存资源的错误会导致比“进程完蛋”更严重的后果，比如用户宁愿经常重启软件也不想自己的数据被破坏（如果不得不在两者间选择的话）。
至于网络连接，比如说网络模块封装了绝大多数的网络操作，而为了封装，网络模块不会把内部的Connection对象的地址泄露到模块外去，因此传出去的都是ConnectionID（一个int），内部用一个hash表映射到Connection对象。而这些ID也是需要管理的，如果管理出错，就会产生错误的映射，而把针对一个连接的操作应用到另一个不相干的连接上。
这种模式在管理其它东西时都可能用到（为了模块的封装性），这里的Connection可能会变成任何其他资源：文件，数据库接口，mutex，硬件的访问接口，或者其他东西。
而“读进来的数据包怎么处理，会不会弄乱”的确属于网络连接管理的范畴，至少在我这里是的，因为我希望网络模块把网络操作尽量封装好，外部使用时不需要针对“网络”这个概念进行太多针对性的操作。所以我的网络模块与上层之间传递的都是消息对象，网络模块负责消息的广播、序列化/还原，还负责调用预处理接口（这里相当于有两次process()的Command），预处理里可能会有加密/解密以及压缩/解压缩，最终上层用的时候就像与本地模块通信那样交换消息对象。