今天一些感想

C++和Java谁快？从算法上讲我认为毫无疑问是汇编〉C++〉Java，不要迷信某些个别评测，单纯的回圈测试什么的，比如JNode的官方网站上有Java写的JVM的性能和SUN的JVM
 
进行性能比较的结果，JNode中用Java写的JVM竟然能比SUN公司用C++写的JVM还快！编译器完全可以作针对性优化影响测试结果，毫无意义的东西。而且，评测结果不会具备多少实际意义，真正的应用系统的效率是80%取决于整体的设计架构，而非你使用哪种语言。所以讨论汇编、C++、Java谁更快这个问题的人恐怕更多是为了自己的面子考虑，虽然Java当前如日中天，但其总是针对C++的批判性态度却再明显不过，所以Bruce才会有“C++不垃圾，只是Java很傲慢”之说。
 
    C++和Java根本的区别是什么？我认为毫无疑问是内存分配。编程思想和设计模式是活的东西，和语言没有直接关系。Java没有指针，C++写程序也可以只用引用。JVM是Java在
 
内存管理上真正有别于C++的地方。JVM的好处是显而易见的，跨平台、更智能的内存管理，但能解决所有问题吗，答案是否定的。
 
    Java没有内存泄露吗?当然不是，我认为java的内存泄露往往比C++更加难以排查，因为JVM的缘故，程序员没法直接对内存进行操控，隐患往往藏的更深。我曾经花了大量时间研究JVM的内存机制，虽然也有了不少心得，但直到现在仍然处于迷惑期。循环引用，缓存机制不合理，Spring等常态Bean的属性重复加载都是可能吃内存的元凶。
 
    对于一个单一的，低用户低并发的系统，使用Java是很舒服的，程序员不用去考虑太多事情，照着业务逻辑做设计编代码就行，不用管内存分配，不用管并发和互斥(其实还是要管的)，就算万一有内存泄露的隐患，大不了每天重启JVM一下就能解决了。但对于一个可能在多个应用环境中部署的软件产品而言，内存泄露这种问题却绝不能放过。我曾经遇到过在一个环境中运行非常良好，但在另一个环境中却天天出问题的情况，即使每天重启JVM也无济于事。当时怀疑过很多方面，网络、数据库、容器等等。那时还不是很有概念，现在想起来还是后来好好看程序，优化了不少代码，解决了几个内存泄露，这样才最终解决了不稳定的问题。举例来讲，在应用环境A中，服务器性能较好，JVM有2G内存，某个应用存在内存泄露的隐患，每次大约造成2M的内存消耗，这样1000次左右就没有内存可用了，就会造成JVM性能大幅降低。但在应用环境B中，服务器就没那么好的性能了，JVM仅有256M，那么100多次操作就足以导致问题出现。而且，每个应用环境的应用使用率是不一样的，在A中如果每天仅出现10次隐患应用操作，2-3个月都不会暴露问题，而且即使使用内存分析工具，开始阶段也很难查出有无问题，但在B中，如果每天有100次隐患应用操作，只需一天问题就出现了。但实际应用过程中，应用的使用率往往很难精确统计的到，也无法预判，这也是造成问题排查困难的关键因素之一。应用环境的不确定性不单体现在地域上，也体现在时间上，不同时间的相同应用环境也不尽相同。挑选一个应用环境，常态性监测JVM的内存情况是避免这类问题发生的好办法。
 
    结论就是，对于中高端的产品化，多用户，高并发应用，Java和C++一样，不考虑内存是不可能的，毕竟语言最终操纵的还是计算机。
 
    那Java的优势在哪里？我认为其在中低端应用上的门槛更低。对大多数小型信息管理类系统而言，并不需要很严谨并且考虑周到的设计和编码，学习java可以让一个新手很快
 
 
 
上路，而C++却没有这种优势，动不动就越界是新手常犯的错误。在一个通常的软件团队里面，水平一定会有高低，而且也不是每个人都能通过学习进入深层次，这是C++难以解决的问题，Java在由于规范性方面的优势更加适合新手使用。
 
    C++就像手动档汽车，Java更像自动档，尽管越来越多人愿意开自动档，可是要想真正跑得快，赛车还得手动挡的。
 
    问题出现总会让人头疼,追根溯源常常也会非常艰苦和漫长,但只要还有办法,就不能放弃,规避问题可以解决阵痛,但永远无法治根。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/chui88/archive/2011/04/18/6330408.aspx