This Is A FineDay

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  93 随笔 :: 0 文章 :: 69 评论 :: 0 Trackbacks

 JVM 内存参数调优

我们前面所提到的堆内存(heap)是由Java虚拟机控制管理的,因此,这些参数对JVM而言都有一个默认值,但在某些情况下这些参数的默认值并不是最优的,这就需要我们通过调整这些参数的值来提高JVM的性能,最终提高应用的性能指标。

在实际的应用开发中,如果应用所使用的系统内存较大,经常会引发内存溢出的错误:

java.lang.OutOfMemoryError <<no stack trace available>>

java.lang.OutOfMemoryError <<no stack trace available>>

    Exception in thread "main"

这可能是因为应用要使用的堆内存(heap)超过了JVM所管理内存范围,如果我们适当追加内存值有时就可以避免这种致命错误的出现。

WINDOWS系统上你可以通过参数-verbosegc查看JVM回收内存的信息,在HP UNIX系统上你可以通过-Xverbosegc:file=/tmp/gc$$.out参数将信息重定向到一个文件中。然后查看相应的信息,例如下面的这个类。

public class A {

       public static void main(String args[]) {

         for (int i =0 ;i < 100000;++i) {

               A a = new A();

         }

         System.out.println("this is a GC test");

       }

}

在类Amain方法中创建了100 000A对象,然后我们看一下JVM回收内存的情况,编译并执行这个类:

>java -verbosegc A

[GC 512K->91K(1984K), 0.0027537 secs]

this is a  GC test

从输出信息中可以看出总共有1984KB的内存被回收,耗时0.002 753 7秒。现在我们将类A添加一行清除对象引用的代码:

public class A {

       public static void main(String args[]) {

         for (int i =0 ;i < 100000;++i) {

               A a = new A();

               a = null;

         }

         System.out.println("this is a GC test");

       }

}

编译并执行这个类:

>java -verbosegc A

[GC 512K->91K(1 984K), 0.0 027 450 secs]

this is a  GC test

我们 看到被回收内存的数量并没有变化,但是回收所需要的时间却变成了0.002 745 0秒,后者比前者节省了0.000 008 7秒,千万不要小看这0.000 008 7秒,当你的应用足够复杂时这个时间就会成指数级增长,看来我们主动清除对象引用的方法,确实可以加速JVM对垃圾内存的回收。

如果再在类A中加入一行强制系统内存回收的代码,结果又会怎样呢?如下所示:

public class A {

    public static void main(String args[]) {

         for (int i =0 ;i < 100000;++i) {

               A a = new A();

               a = null;

         }

         System.gc();

         System.out.println("this is a GC test");

    }

}

编译并执行这个类:

>java -verbosegc A

[GC 512K->91K(1984K), 0.0 027 272 secs]

[Full GC 487K->91K(1984K), 0.0 070 730 secs]

this is a  GC test

系统 这次做了两次内存回收,第一次是程序中强制系统内存回收的代码System.gc()导致的内存回收,而后者是系统最终的内存回收操作,我们看到强制内存回收耗时不长,可是却导致了系统最终垃圾回收的时间加长了很多,因此我们在采用强制系统垃圾回收(通过显式调用方法System.gc())的办法来回收系统垃圾内存的办法,还是存在一些弊端的,应尽量少用,或者说只在必要的时候应用。

上面我们提到的内存回收操作就是回收JVM所 管理的堆内存(heap)。当系统连续申请内存并且超过JVM所管理的堆内存(heap)的最大值时,就会产生系统内存溢出的致命异常,下面我们来看一下 怎样通过设置JVM的内存参数来优化JVM对内存的管理,避免内存溢出异常的发生。表2-1所示的就是与JVM内存相关的参数及其说明。

 

 

 

 

 

 

2-1  JVM内存相关的参数及其说明

JVM 堆内存(heap)设置选项

参数格式

   

设置新对象生产堆内存(Setting the Newgeneration heap size

-XX:NewSize

通过这个选项可以设置Java新对象生产堆内存。在通常情况下这个选项的数值为1 024的整数倍并且大于1MB。这个值的取值规则为,一般情况下这个值-XX:NewSize是最大堆内存(maximum heap size)的四分之一。增加这个选项值的大小是为了增大较大数量的短生命周期对象

增加Java新对象生产堆内存相当于增加了处理器的数目。并且可以并行地分配内存,但是请注意内存的垃圾回收却是不可以并行处理的

续表 

JVM 堆内存(heap)设置选项

参数格式

   

设置最大新对象生产堆内存(Setting the maximum New generation heap size

-XX:MaxNewSize

通过这个选项可以设置最大Java新对象生产堆内存。通常情况下这个选项的数值为1 024的整数倍并且大于1MB

其功用与上面的设置新对象生产堆内存-XXNewSize相同

设置新对象生产堆内存的比例(Setting New heap size ratios

-XX:SurvivorRatio

新对象生产区域通常情况下被分为3个子区域:伊甸园,与两个残存对象空间,这两个空间的大小是相同的。通过用-XX:SurvivorRatio=X选项配置伊甸园与残存对象空间(Eden/survivor)的大小的比例。你可以试着将这个值设置为8,然后监控、观察垃圾回收的工作情况

设置堆内存池的最小值

Setting minimum heap size

-Xms

通过这个选项可以要求系统为堆内存池分配内存空间的最小值。通常情况下这个选项的数值为1 024的整数倍并且大于1MB。这个值的取值规则为,一般情况下这个值(-Xms)与最大堆内存相同,以降低垃圾回收的频度

设置堆内存池的最大值(Setting maximum heap size

-Xmx

通过这个选项可以要求系统为堆内存池分配内存空间的最大值。通常情况下这个选项的数值为1 024的整数倍并且大于1 MB

一般情况下这个值(-Xmx)与最小堆内存(minimum heap size –Xms)相同,以降低垃圾回收的频度

取消垃圾回收

-Xnoclassgc

这个选项用来取消系统对特定类的垃圾回收。它可以防止当这个类的所有引用丢失之后,这个类仍被引用时不会再一次被重新装载,因此这个选项将增大系统堆内存的空间

设置栈内存的大小

-Xss

这个选项用来控制本地线程栈的大小,当这个选项被设置的较大(>2MB)时将会在很大程度上降低系统的性能。因此在设置这个值时应该格外小心,调整后要注意观察系统的性能,不断调整以期达到最优

根据表2-1中所描述的参数意义,我们可以在启动应用时为JVM设置相应的参数值以提高系统的性能,例如下面的例子:

java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8  -Xms512m

-Xmx512m MyApplication

类文件(.class)的大小

Java源文件.java文件编译成JVM 可解释执行的Java字节文件.class。因所采用的编译方式的不同而大小也不同。通常.class文件的大小也存在是否占用较大内存的问题。通过降 低.class文件的大小,不但可以降低系统内存的开销,还可以节省网络开销,虽然这部分内容与JVM内存管理联系不大,但是我觉得还是有必要提一下,因 为这在你开发Applet应用时会有帮助(注:在本书后续的章节中,将会对如何减小Java类尺寸的技术话题做更为深入的探讨)。因为一般来说, Applet应用都是靠网络分布式传输由客户端浏览器装载运行的,如果类文件较大,无疑将会增大网络开销,降低传输速度无法满足用户的需求,并且如果类文件较大,无疑也会消耗客户端内存资源。我们可以通过在Java编译器javac中添加相应的参数,来缩小类文件的大小,解决上面的问题。

通常有三种编译方式会影响类文件的大小。

1)默认编译方式:  javac   A.java

2)调试编译方式:  javac  –g A.java

3)代码编译方式:  javac  –g:none A.java

例如如下所示的简单的类A

public class A {

       public static void main(String args[]) {

          for (int i =0 ;i < 100000;++i) {

          A a = new A();

          }

       }

}

通过上面这三种方式编译后的类文件的大小分别为:

默认编译方式:291字节。

调试编译方式:422字节。

代码编译方式:207字节。

采用三种不同的方式,编译产生的类文件的大小差异非常大,这是什么原因导致的呢?原来在于.class文件中包含多个不同的部分或属性。

代码(Code)属性包含实际的方法字节码。 源文件信息(SourceFile Information)包含用于生成.class的源文件名称。代码行序号表(LineNumberTable)用来映射源文件中的代码行序号与字节码 文件中的序号偏移。本地变量表(LocalVariableTable)用来映射本地变量与栈桢的偏移。

& 注意  如果你想了解字节码文件.class的文件结构详细信息,请参考相关的技术资料,这里就不详细讲解了。

正是由于上面这三种编译方式生成的类文件所包含的信息不同,才导致了类文件的大小差异较大,其包含的信息分别如下所示。

默认编译方式:代码(Code)、源文件信息(SourceFile Information)、代码行序号表(LineNumberTable)。

调试编译方式:代码(Code)、源文件信息(SourceFile Information)、代码行序号表(LineNumberTable)、本地变量表(LocalVariableTable)。

代码编译方式:代码(Code)。

这就是三种编译方式产生类文件大小不同的根本原因。而这三种编译方式在程序开发的不同阶段却都起着非常重要的作用,例如,调试编译方式在程序的调试开发过程中应采用,以获取更为详细的调试信息。因此具体应用上面的三种编译方式中的哪一种,应该适时而定。

 

posted on 2008-01-14 13:55 Peter Pan 阅读(2444) 评论(0)  编辑  收藏 所属分类: J2EE

只有注册用户登录后才能发表评论。


网站导航: