Java Trouble Shooting - 关于性能瓶颈

0

性能优化的理念

粗略地划分,代码可分为 cpu consuming 和 io consuming 两种类型,即耗 CPU 的和耗 IO 的代码。如果当前CPU已经能够接近100%的利用率, 并且代码业务逻辑无法再简化, 那么说明该系统的已经达到了性能最大化, 如果再想提高性能, 只能增加处理器(增加更多的机器或者安装更多的CPU)。
而耗 IO 的代码,一般体现为请求某种资源,这可以是访问数据库,或者访问网络对端。

评价程序写得好不好,要看随着访问压力的上升,CPU 使用率的变化,好的代码,随着访问压力的上升,CPU 的使用率最终能趋近100%,而坏的代码,使用率始终无法趋近 100%,有可能在 70% 就已经上不去了。好的代码应该在代码本身效率足够高的情况下,通过使用并发等手段,让 CPU 的尽量地忙起来。随着访问压力的上升,CPU 使用率也上升,并且 CPU 所跑的代码都是已经无法再进行逻辑优化或者效率提升的代码,这是最理想的状态。

常见性能瓶颈

多余的同步

不相关的两个函数, 共用了一个锁,或者不同的共享变量共用了同一个锁, 无谓地制造出了资源争用,如下代码所示:

class MyClass {
  Object sharedObj;
  synchronized void fun1() {...} //访问共享变量sharedObj
  synchronized void fun2() {...} //访问共享变量sharedObj
  synchronized void fun3() {...} //不访问共享变量sharedObj
  synchronized void fun4() {...} //不访问共享变量sharedObj
  synchronized void fun5() {...} //不访问共享变量sharedObj
}

上面的代码将sychronized加在类的每一个方法上面, 违背了保护什么锁什么的原则。对于无共享资源的两个方法, 使用了同一个锁, 人为造成了不必要的锁等待。 上述的代码可作如下修改:

class MyClass {
  Object sharedObj;
  synchronized void fun1() {...} //访问共享变量sharedObj
  synchronized void fun2() {...} //访问共享变量sharedObj
  void fun3() {...} //不访问共享变量sharedObj
  void fun4() {...} //不访问共享变量sharedObj
  void fun5() {...} //不访问共享变量sharedObj
}

锁粒度过大

对共享资源访问完成后, 没有将后续的代码放在synchronized同步代码块之外。 这样会导致当前线程长时间无谓的占有该锁, 其它争用该锁的线程只能等待, 最终导致性能受到极大影响。如下代码所示:

void fun1() {
    synchronized(lock){
    ... ... //正在访问共享资源
    ... ... //做其它耗时操作,但这些耗时操作与共享资源无关
  }
}

上面的代码, 会导致一个线程过长地占有锁, 而在这么长的时间里其它线程只能等待。应将上述代码作如下修改,在多 CPU 的环境中,可获得性能的提升:

void fun1() {
  synchronized(lock) {
    ... ... //正在访问共享资源
  }
  ... ... //其它耗时操作代码拿到synchronized代码外面
}

字符串连接的滥用

String c = new String("abc") + new String("efg") + new String("12345");

每一次+操作都会产生一个临时对象, 并伴随着数据拷贝, 这个对性能是一个极大的消耗。 这个写法常常成为系统的瓶颈, 如果这个地方恰好是一个性能瓶颈, 修改成StringBuffer之后, 性能会有大幅的提升。

不恰当的线程模型

在多线程场合下, 如果线程模型不恰当, 也会使性能低下,在网络IO的场合, 使用消息发送队列和消息接收队列来进行异步IO,性能会有显著的提升。

消息接收
消息发送

不恰当的 GC 参数

不恰当的GC参数设置会导致严重的性能问题,比如堆内存设置过小导致大量的 CPU 时间片被用来做垃圾回收

扫一扫关注我的微信公众号


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

载入中...