摘要：不知不觉，做程序员工作已经10年了，从最初学习C++到Java，从困惑到清晰，感觉真的有不少东西可写，不过总觉得不成体系，大概看了太多八股文章的缘故，被憋得实在难受。所以不管了，想到什么写什么吧。

　　不知不觉，做程序员工作已经10年了，从最初学习C++到Java，从困惑到清晰，感觉真的有不少东西可写，不过总觉得不成体系，大概看了太多八股文章的缘故，被憋得实在难受。所以不管了，想到什么写什么吧。

　　1、从C++到Java

　　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更像自动档，尽管越来越多人愿意开自动档，可是要想真正跑得快，赛车还得手动挡的。

　　问题出现总会让人头疼,追根溯源常常也会非常艰苦和漫长,但只要还有办法,就不能放弃,规避问题可以解决阵痛,但永远无法治根。

　　2、关于云计算想到的

　　毫无疑问云计算的概念被扩大化了，云服务、云存贮，SAAS、IAAS、PAAS，理论和概念早已满天飞。但当我仔细读来，却发现大多还是新瓶装旧酒。虽然说还是有不少实质性内容，但与真正的分布式计算概念还是想去甚远。在网络越来越发达的时代背景下，存贮、软件、外设甚至内存都网络化了，唯一缺少的就是CPU，依靠网络使大量CPU协同工作真的是个很诱人的想法，但也是困难而遥远的事情。也有人认为Cloud Computing是个过度炒作的东西，我觉得有一定道理，如果要我选择，我也会希望把自己的东西放到自己的电脑上，我会更希望在任何地方使用便携设备随时操纵我的电脑，却绝对不是放到一个看不见摸不到的“云端”上头，天天被“云端”盘剥和控制。因此，如果云端仅仅是服务或存贮的集中式管理，它是不值得如此进行炒作的。

　　其实我觉得我不是一个重组概念进行炒作的反对者，炒作对于技术和社会进步是有一定作用的，但水可载舟、亦可覆舟，将一些本无关系的东西牵强附会的联系在一起进行炒作，只会搅乱理论和学术体系，而理论体系的混乱一定会导致交流上的障碍-----虽然交流变得更多（必然变得更多）更方便了，可是交流的障碍却大幅度增加了，同样的一个名词可以被一百个人给出一百个解释，本来一句话可以说清楚的事情，现在变成了几十句才能说明白。

　　药厂可以把10几块钱的药重新包装卖200-300块，利润当然是惊人的，可是赚到了钱的老板们却天天打算着转移资产到国外，认为国内没有可持续的发展。这样的人到底是高素质还是低素质呢？

　　我上大学的时候曾经在医院实习，见过一个食物中毒的病人家属连夜赶了几十里山路，把一堆借来的硬币交给医院做透析；后来工作了，搞图书馆的项目也知道很多地方的人连100块钱的借书证押金都捉襟见肘。那些天天生活在优越环境下的概念重组专家们会为这些人群考虑多少呢？“云端”的概念炒作显现了他们的垄断思想，现在中国的贫富差距基本还是在财产方面，信息方面基本还是对等的，这也是一个农村的孩子经过十几年苦干可以成为大企业家的前提所在。可是“云端” 一来，你的一举一动都在我掌控和监视之下，没错，你是方便了，也少花钱了，可是却失去了信息方面的平等地位，于是，屁民将永远是屁民，永远没有咸鱼翻身的机会。

　　3、关于信息爆炸

　　10年来我也做了很多技术方面的工作了，最初几年看到一项新技术、新概念，肾上腺激素浓度就会大幅度增加，要是不用一下晚上恐怕觉都睡不着。可是后来慢慢地就变得理性多了，技术的选择一定要根据需求来，绝不能为用技术而用技术。很多的新技术、新概念，看几眼就差不多知道来源，也知道优点和缺点了。以前总以为环境得适应程序，后来明白了程序得适应环境。

　　大型的应用系统，越简单越好，如果做不到简单，宁可拆分为多个系统单独设计。否则，当我面对一大堆连自己都难以看懂的概念和代码，真会有抓狂的感觉。

　　CSDN是不错的技术社区了，但是依然缺乏体系组织和管理。论坛、知识库，Q&A，这些东西的模式差不多，虽然方便了信息交流，但缺乏信息的组织和管理。比如我希望做一个信息系统，那应该选择什么样的技术？这个问题目前只能靠自己去摸索，慢慢体会，找到真正适合自己的技术方案。Wiki可能是更好的平台，但普及度不够。

　　其实每一个Questioner或者Answerer都在极力寻求相互之间的共同语言，共同语言和语义的理论体系形成之后，交流才能顺畅。翻翻 CSDN的帖子，不乏问东答西的案例。一个交流平台如果能形成一套语言和思维方式，那就是非常成功的了。而这也使得技术选型的模型成为可能，当你想采用一套新技术时，Google一下，各说各话，对的有，错的也有，搜索引擎为何判断不出已定论的东西谁对谁错呢，就是源于语义的复杂性。信息的膨胀速度远没有我们想象中那样快，其中相当一部分是语言语义产生的泡沫，挤掉这些泡沫呢？信息真的有统计数据显示的那么“海量”吗？

　　统计数据经常是面子工程强有力的支撑者，可扔掉这些浮华，细细究一下统计数据是怎么做出来的？常常就会让人哭笑不得，而且大多是7分真，3分假，或偷换概念，总之目的就是把一棵小草说成一座森林。信息是有欺骗性的，商业运作会大量运用这种特性，换来的除了肾上/腺素之外还有人和人之间不信任的感觉。

　　信息爆炸的时代，交流的作用变成空前重要，但在交流越来越方便的同时，效率也越来越低了。也许几十年后，人类会不堪信息的重负，那时信息规范化和有序化才会真正站上历史的舞台。