虚拟机(JVM)常见的5个调优问题及解决方案

  1. 高性能硬件上JVM运行速度却不够快,有时出现长时间停顿
  2. 集群间同步导致的内存溢出
  3. 堆外内存导致的溢出错误
  4. 外部命令导致的系统缓慢
  5. 不恰当的数据结构导致内存占用过大

高性能硬件上JVM运行速度却不够快,有时出现长时间停顿

例如将32为系统的服务器替换为64为操作系统,4CPU,16GB物理内存的新硬件,用以解决用户浏览网页缓慢的问题,第一种方式是通过使用64位JDK来使用大内存,第二中方式是通过使用若干个32位虚拟机建立起逻辑集群来利用硬件资源。

第一种方式的使用前提是需要把Full GC的频率控制的足够好,否则频繁的Full GC会严重影响用户的体验,由于内存较大,一次Full GC的时间也会相当长,十几G的堆内存一次Full GC会长达十几秒,尤其是当系统中存在大量“长命”的大对象时,Full GC会更容易被触发。这就是为啥升级了硬件反而系统变得更糟糕的原因,因此通过这种方式来实现系统响应速度的提升,代码必须要写的合理,尽可能的降低Full GC出现的频率,不仅如此,系统管理者还需要面临如下问题:

  • 64为JDK的性能测试结果普遍低于32位JDK
  • 需要保证程序足够稳定,因为几乎无法产生十几G的堆转储快照,即便产生了也难以分析问题
  • 由于指针膨胀以及数据类型对其补白,导致相同程序消耗的内存,64位JDK大于32位JDK

第二方式的具体做法是在一台物理机上启动多个应用服务进程,每个进程分配不同的端口,然后在前端搭建一个负载均衡器,以反向代理的方式分配访问请求。因为仅仅是为了提高硬件资源利用率,所以不需要关心状态保留,热转移之类的高性能问题。也不需要绝对准确的负载均衡。因此使用无Session复制的亲和式集群是一个不错的选择。这种方式看上去完美解决了我们的问题,但是仍然由不足之处:

  • 集群各节点竞争全局资源导致的问题
  • 各资源池在各节点单独存在,导致资源浪费
  • 单个节点仍受到32位JDK的内存限制
  • 若使用本地缓存,会因为各节点都有一份缓存而导致内存浪费,可以改成集中式缓存。

集群间同步导致的内存溢出

在集群环境中,有写需求需要实现节点之间数据共享,如果将共享数据存储在数据库中,由于读写频繁,竞争激烈,对性能的影响较大,如果使用JBossCache构建一个全局缓存,一般情况下不会出现问题,但当网络不稳定时,若进行频繁的写操作,这样会产生很大的网络开销,使得大量数据等待写入而堆积在内存中,最终导致内存溢出。

堆外内存导致的溢出错误

堆外内存的垃圾收集不像新生代和老年代那样,当发现内存不足时触发GC,Direct Momory的内存回收只能在Full GC发生时顺便的帮忙清理掉废弃对象,否则只能当发现内存溢出时先chach,然后再主动提醒GC,若虚拟机还是不能及时回收,只能抛出内存溢出异常。除了Java堆和永久代之外,还有一些区域会占用较多内存,如线程堆栈,Socket缓存区,JNI代码,虚拟机和GC,这额内存的总和受到操作系统进程最大内存的影响。

外部命令导致的系统缓慢

当请求伴随着外部命令的调用时(如Runtime.getRuntime().exec()),Java虚拟机执行这个命令的过程是:首先克隆一个和当前虚拟机拥有相同环境变量的进程,然后用该进程去执行命令,执行完毕后再推出这个进程。对然外部命令能很快执行完毕, 但是频繁的进程创建资源开销很大,不仅是CPU,内存负担也会很重,因此会导致系统运行缓慢。

不恰当的数据结构导致内存占用过大

例如加载一个80M的数据文件到内存中解析,如果解析成HashMap数据结构,将会产生100W个HashMap Entry,若采用的是PartNew收集器,由于该收集器是采用复制算法,这个算法的高效时间里再大部分对线故事朝生夕灭的特性上,如果存活对象过多,把这些对象复制到Survivor并维持这些对象的正确引用,就会导致GC时间明显边长。要从根本上解决问题就需要避免使用HashMap这种空间利用率底下的数据结构(空间利用率=有效数据大小/占用总空间)

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值