JVM优化配置

相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

JVM优化配置

OOM这个缩写就是Java程序开发过程中让人最头痛的问题:Out of

Memory在很多开发人员的开发过程中,或多或少的都会遇到这类问题,这类问题定位比较困难,往往需要

根据经验来判断可能出现问题的代码。原因主要是

两个:对象没有被释放(多种情况引起,往往是比较隐蔽的引用导致被Hold而无法被回

收)。另一种就是真的 Memory不够用了,需要增加 JVM的

Heap来满足应用程序的需求。最近有同事发的关于解决OOM勺问题,让我了解了原来 OOM

除了在JVM Heap不够时会发生,在 Native

Heap不够的时候也会发生,同时JVM Heap和Native

Heap存在着相互影响和平衡的关系,因此就仔细的去看了关于 OOM和JVM配置优化的内

容。

OOM

其他语言类似于 C,Delphi等等由于内存都是由自己分配和管理,因此内存泄露的问题比

较常见,同时也是很头痛的一件事情。而Java的对象生命周期管

理都是JVM来做的,简化了开发人员的非业务逻辑的处理,但是这种自动管理回收机制也是基于一些规则的,而违背了这些规则的时候,就会造成所谓的

“Memory Leak'。

OOM(Java Hea p)

错误提示: ng.OutOfMemoryError 。

这类OOMi由于JVM分配的给应用的 Heap

Memory已经被耗尽,可能是因为应用在高负荷的情况下的却需要很大的内存,因此可以通过修改JVM参数来增加 Java Heap

Memory (不过也不能无限制增加,后面那种OOMt可能就是因为这个原因而产生)。另

一种情况是因为应用程序使用对象或者资源没有释放,导致内存消耗

持续增加,最后出现 OOM这类问题引起的原因往往是应用已不需要的对象还被其他有效对象所引用,那么就无法释放,可能是业务代码逻辑造成的(异常处理不够例如10等资源),也可能是对于第三方开源项目中资源释放了解不够导致使用以后资源没有释放(例如 JDBC的Resultset等)。

几个容易出现问题的场景:

1.应用的缓存或者Collection :如果应用要缓存 Java对象或者是在一个

Collection 中保存对象,那么就要确定是否会有大量的对象存入,要做保护,以防止在

大数据量下大量内存被消耗,同时要保证Cache的大小不会无限制增加。

2.生命周期较长的对象:尽量简短对象的生命周期,现在采用对象的创建

释放代价已经很低,同时作了很好的优化,要比创建一个对象长期反复使用要好。如果

能够设置超时的情景下,尽量设置超时。

10这类资源的释放都需要注意。

Windows 为2G 然而这些大小的内存并不会全部给 JVM 的 Java

3 .类似于 JDBC 的 Connection Pool ,在使用Pool 中的对象以后需要释放 并返回,不然就会造成Pool 的不断增大,在其他 Pool 中使用也是一样。同样ResultSet ,

解决的方法就是查找错误或者是增加 Java Heap Memory 。对于此类问题检

测工具相当多,这里就不做介绍了。 OOM(Native Hea p)

错误提示:requested XXXX bytes for ChunkPo ol::allocate. Out of swa p space

Native Heap Memory 是 JVM

内部使用的Memory 这部分的Memory 可以通过JDK 提供的JNI 的方式去访问,这部分 Memory 效率很高,但是管理需要自己去做,如果没有把 握最好不要使用,以防出现内存泄露问题。

JVM 使用 Native Heap

Memory 用来优化代码载入(JTI 代码生成),临时对象空间申请,以及 JVM 内部的一些

操作。这次同事在压力测试中遇到的问题就是这类

OOM 也就是

这类Memory 耗尽。同样这类OOM 产生的问题也是分成正常使用耗尽和无释放资源耗尽两 类。无释放资源耗尽很多时候不是程序员自身的原因,可能是引用的 第三方包的缺陷,例如很多人遇到的 Oracle 9 JDBC 驱动在低版本中有内存泄露的问题。 要确定这类问题,就需要去观察

Native Heap

Memory 的增长和使用情况,在服务器应用起来以后,运行一段时间后 JVM 对于 Native

Hea P

Memory 的使用会达到一个稳定的阶段,此时可以看看什么操作对于 操作频繁,而且使得 Native Hea p Memory 增长,对于 Native Heap

Memory 的情况我还没有找到办法去检测,现在能够看到的就是为 -verbose:j ni 参数来观察对于 Native Hea p

Native Heap Memory

JVM 启动时候增加

,对于 Native Heap

Memory 的操作。另一种情况就是正常消耗 Native Hea p Memory

Memory 的使用主要取决于 JVM 代码生成,线程创建,用于优化的临时代码和对象产生。 当正常耗尽Native Heap

Memory 时,那么就需要增加 Native Heap Memory ,此时就会和我们前面提到增加 java

Heap Memory 的情况出现矛盾。 应用内存组合

于应用来说,可分配的内存受到 OS 的限制,不同的 OS 对进程所能访问虚拟内存地址区 间直接影响对于应用内存的分配,

32位的操作系统通常最大支持

4G 的内

存寻址,而Linux —般为3G

相关文档
最新文档