1700452300
（3）变更GC的垃圾回收策略
1700452301
1700452302
Java程序性能的最大障碍就是垃圾回收，我们不知道它何时会发生，也不知道它会执行多长时间，但是我们可以想办法改变它对系统的影响，比如启用并行垃圾回收、规定并行回收的线程数量等，命令格式如下：
1700452303
1700452304
java-XX：+UseParallelGC-XX：ParallelGCThreads=20
1700452305
1700452306
这里启用了并行垃圾收集机制，并且定义了20个收集线程（默认的收集线程等于CPU的数量），这对多CPU的系统是非常有帮助的，可以大大减少垃圾回收对系统的影响，提高系统性能。
1700452307
1700452308
当然，垃圾回收的策略还有很多属性可以修改，比如UseSerialGC（启用串行GC，默认值）、ScavengeBeforeFullGC（新生代GC优先于Full GC执行）、UseConcMarkSweepGC（对老生代采用并发标记交换算法进行GC）等，这些参数需要在系统中逐步调试。
1700452309
1700452310
（4）更换JVM
1700452311
1700452312
如果所有的JVM优化都不见效，那只有使用最后一招了：更换JVM，目前市面上比较流行的JVM有三个产品：Java HotSpot VM、Oracle JRockit JVM、IBM JVM，其中HotSpot是我们经常使用的，稳定性、可靠性都不错；JRockit则以效率著称，性能是它的优势，但在决定使用该JVM之前一定要做好全面的系统测试，它的某些行为可能会在JRockit上产生Bug；IBM JVM也比较稳定，而且它在AIX系统上的表现要远远好于其他操作系统。
1700452313
1700452314
JVM的优化不能像程序优化一样，找到Bug就可以立刻解决，JVM的优化一定是要循序渐进的，参数设置不可激进，特别是需要优化多个参数时，一定要逐步实施，确保每个优化步骤都达到了预期目标，否则会对整个系统的稳定性产生较大的风险。需要提醒的是以上带有“-XX”的JVM参数可能是不健壮的，SUN也不推荐使用，可能后续会在没有通知的情况下就不再支持它了，但是它又非常好用，这需要在系统升级、迁移时慎重考虑。
1700452315
1700452316
1700452317
1700452318
1700452320
编写高质量代码：改善Java程序的151个建议 建议138：性能是个大“咕咚”
1700452321
1700452322
有一部动画片叫《咕咚来了》，其大致剧情是：三只小兔在湖边玩耍，忽然湖中传来“咕咚”一声，这奇怪的声音把小兔们吓了一大跳。小兔们刚想去看个究竟，又听到“咕咚”一声，这可把小兔们吓坏了，“快跑，咕咚来了，快逃呀！”小兔们转身就跑。
1700452323
1700452324
狐狸正同小鸟跳舞，与跑来的兔子碰了个满怀。狐狸一听“咕咚来了！”也紧张起来，跟着就跑。它们又惊醒了睡觉的小熊和树上的小猴，小熊和小猴也不问青红皂白，跟着它们跑起来，于是一路上跟着跑的动物越来越多，大象、河马、老虎、野猪……
1700452325
1700452326
岸上这阵骚乱，让湖中的青蛙感到十分惊讶，它拦住了这群吓蒙了的伙伴们，问出了什么事，大家七嘴八舌地形容“咕咚”是个多么可怕的怪物。青蛙问：“谁见到了？”大家互相推诿，谁也没有亲眼看见，于是决定回去看看明白。
1700452327
1700452328
回到湖边，又听见“咕咚”一声，仔细一看，原来是木瓜掉进水里发出的声音，众动物不禁大笑起来。
1700452329
1700452330
这寓言故事好笑吗？很好笑，但是要是发生在我们自己身上就不那么好笑了，比如说，某些Javaer一直在质疑Java系统的性能，于是我们自己也跟着怀疑Java的性能—这就是发生在我们身边的真实“咕咚”，Java系统的性能问题本就是子虚乌有的事情，是我们自己吓唬自己，其实，我们可以从四个方面分析该问题：
1700452331
1700452332
（1）没有慢的系统，只有不满足业务的系统
1700452333
1700452334
不管是使用C开发还是Java开发的项目，最终都会有一个产品诞生，或服务于大众（如网站），或服务于企业（企业级应用），谁来决定一个系统的快慢呢？不是计算机，它只会使用毫秒、纳秒去记录时间但不会做判断，它可以计算出一个交易执行了多长时间，但它不能决定这个时间是长还是短，那谁去判断呢？是人，准确地说是使用者，即使是开发人员自己根据日志记录的时间来判断系统是慢了还是快了，那也还是以使用者的身份来判断的，对一个系统毫无了解的人员是无法判断出一个系统的快慢的。
1700452335
1700452336
例如一个做统计的业务人员去看计费系统，即使响应需要N秒的时间，统计人员也会觉得非常快了，那是因为统计系统的结果经常是按照小时、天来计算的。再比如即时通信系统，有1秒内的延迟是可以接受的（发送者发出消息到接受者接收消息的时间间隔为1秒），但是语音通信系统若有1秒的延迟就是不可接受的了；发送邮件N分钟后才收到，这是可以容忍的，但是对于同城银行内转账来说，这个时间就是不可容忍的，必须在秒级完成。不同的系统所要求的性能不同，因此只要一个系统达到业务要求就可以认为它足够快，我们不要期望跨系统间的性能对比，这是毫无意义的。
1700452337
1700452338
如果有使用者告诉你，“这个系统太慢了”，也就是在间接地提醒您：系统没有满足业务需求，尚待继续努力。
1700452339
1700452340
（2）没有慢的系统，只有架构不良的系统
1700452341
1700452342
在做系统架构设计时，架构师有没有考虑并行计算？有没有考虑云计算技术？有没有负载均衡？……这些都是解决我们性能问题的良方，只要架构设计得当，效率就不是问题。
1700452343
1700452344
即使是架构初期没有考虑扩展性，那我们也有一些手段可解决性能问题。比如有一个批处理系统，系统建设时的目标是：5小时内生成2000万条业务数据，可到第3年的时候，公司发生了大规模的变化（整合了其他同类公司），需要处理的数据更多了，在5小时内需要生成8000万业务。于是就得考虑架构的扩展了。有一个很简单的处理方案，即应用服务器水平扩展，增加业务数据源的纵向切割能力，均分数据压力，这样就可以很轻松地实现大数量的生成。
1700452345
1700452346
再比如，一个新闻网站，刚开始上线时访问的人员不多，响应都是在毫秒级别的，随着访问量的激增，响应时间呈阶梯型增加，资深会员流失率翻倍跳跃，如何解决该问题呢？解决方案有两个：一是增加IP层的负载均衡，或者硬件设备，或者软件架构，把访问者分配到多个不同的应用服务器上，降低单台应用服务器的性能压力；二是增强系统的处理能力，增大吞吐量，比如提升数据源的响应能力，划分数据的热度（如把数据划分为Hot、Warm、Cold等区域，分配不同的硬件资源和服务等级），很多时候这两个方案配合起来使用，会很快解决性能问题。
1700452347
1700452348
（3）没有慢的系统，只有懒惰的技术人员
1700452349
[
上一页 ]
[ :1.7004523e+09 ]
[
下一页 ]