深入Java虚拟机之内存优化

标签: java 虚拟机 内存 | 发表时间:2011-12-27 17:28 | 作者:
出处:http://www.iteye.com

前面一篇文章介绍了Java虚拟机的体系结构和内存模型,既然提到内存,就不得不说到内存泄露。众所周知,Java是从C++的基础上发展而来的,而C++程序的很大的一个问题就是内存泄露难以解决,尽管Java的JVM有一套自己的垃圾回收机制来回收内存,在许多情况下并不需要java程序开发人员操太多的心,但也是存在泄露问题的,只是比C++小一点。比如说,程序中存在被引用但无用的对象:程序引用了该对象,但后续不会或者不能再使用它,那么它占用的内存空间就浪费了。

 

我们先来看看GC是如何工作的:监控每一个对象的运行状态,包括对象的申请、引用、被引用、赋值等,当该对象不再被引用时,释放对象(GC本文的重点,不做过多阐述)。很多Java程序员过分依赖GC,但问题的关键是无论JVM的垃圾回收机制做得多好,内存总归是有限的资源,因此就算GC会为我们完成了大部分的垃圾回收,但适当地注意编码过程中的内存优化还是很必要的。这样可以有效的减少GC次数,同时提升内存利用率,最大限度地提高程序的效率。

 

总体而言,Java虚拟机的内存优化应从两方面着手:Java虚拟机和Java应用程序。前者指根据应用程序的设计通过虚拟机参数控制虚拟机逻辑内存分区的大小以使虚拟机的内存与程序对内存的需求相得益彰;后者指优化程序算法,降低GC负担,提高GC回收成功率。

 

通过参数优化虚拟机内存的参数如下所示:
-Xms
初始Heap大小

-Xmx
java heap最大值 

-Xmn
young generation的heap大小

-Xss
每个线程的Stack大小

上面是三个比较常用的参数,还有一些:
-XX:MinHeapFreeRatio=40
Minimum percentage of heap free after GC to avoid expansion.
 
-XX:MaxHeapFreeRatio=70
Maximum percentage of heap free after GC to avoid shrinking.
 
-XX:NewRatio=2
Ratio of new/old generation sizes. [Sparc -client:8; x86 -server:8; x86 -client:12.]-client:8 (1.3.1+), x86:12]
 
-XX:NewSize=2.125m
Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86:1m; x86, 5.0 and older: 640k]
 
-XX:MaxNewSize=
Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio.
 
-XX:SurvivorRatio=25
Ratio of eden/survivor space size [Solaris amd64: 6; Sparc in 1.3.1: 25; other Solaris platforms in 5.0 and earlier: 32]
 
-XX:PermSize=
Initial size of permanent generation
 
-XX:MaxPermSize=64m
Size of the Permanent Generation.  [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]


下面所说通过优化程序算法来提高内存利用率,并降低内存风险,完全是经验之谈,仅供参考,如有不妥,请指正,谢谢!


1.尽早释放无用对象的引用(XX = null;)   

看一段代码:

 

public List<PageData> parse(HtmlPage page) {
        List<PageData> list = null;        
        try {
            List valueList = page.getByXPath(config.getContentXpath());
            if (valueList == null || valueList.isEmpty()) {
                return list;
            }
            //需要时才创建对象,节省内存,提高效率
            list = new ArrayList<PageData>();
            PageData pageData = new PageData();
            StringBuilder value = new StringBuilder();
            for (int i = 0; i < valueList.size(); i++) {
                HtmlElement content = (HtmlElement) valueList.get(i);
                DomNodeList<HtmlElement> imgs = content.getElementsByTagName("img");
                if (imgs != null && !imgs.isEmpty()) {
                    for (HtmlElement img : imgs) {
                        try {
                            HtmlImage image = (HtmlImage) img;
                            String path = image.getSrcAttribute();
                            String format = path.substring(path.lastIndexOf("."), path.length());
                            String localPath = "D:/images/" + MD5Helper.md5(path).replace("\\", ",").replace("/", ",") + format;
                            File localFile = new File(localPath);
                            if (!localFile.exists()) {
                                localFile.createNewFile();
                                image.saveAs(localFile);
                            }
                            image.setAttribute("src", "file:///" + localPath);
                            localFile = null;
                            image = null;
                            img = null;
                        } catch (Exception e) {
                        }
                    }
                    //这个对象以后不会在使用了,清除对其的引用,等同于提前告知GC,该对象可以回收了
                    imgs = null;
                }
                String text = content.asXml();
                value.append(text).append("<br/>");
                valueList=null;
                content = null;
                text = null;
            }
            pageData.setContent(value.toString());
            pageData.setCharset(page.getPageEncoding());           
            list.add(pageData);
            //这里 pageData=null; 是没用的,因为list仍然持有该对象的引用,GC不会回收它
            value=null;
            //这里可不能 list=null; 因为list是方法的返回值,否则你从该方法中得到的返回值永远为空,而且这种错误不易被发现、排除
        } catch (Exception e) {            
        }        
        return list;
}


2.谨慎使用集合数据类型,如数组,树,图,链表等数据结构,这些数据结构对GC来说回收更复杂。
3.避免显式申请数组空间,不得不显式申请时,尽量准确估计其合理值。
4.尽量避免在类的默认构造器中创建、初始化大量的对象,防止在调用其自类的构造器时造成不必要的内存资源浪费
5.尽量避免强制系统做垃圾内存的回收,增长系统做垃圾回收的最终时间
6.尽量做远程方法调用类应用开发时使用瞬间值变量,除非远程调用端需要获取该瞬间值变量的值。
7.尽量在合适的场景下使用对象池技术以提高系统性能

 

 

原创文章,转载请注明出处: http://yshjava.iteye.com/blog/1328015

 

 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [java 虚拟机 内存] 推荐:

Java虚拟机学习 - 内存调优

- - CSDN博客推荐文章
JVM调优主要是针对内存管理方面的调优,包括控制各个代的大小,GC策略. 由于GC开始垃圾回收时会挂起应用线程,严重影响了性能,调优的目是为了尽量降低GC所导致的应用线程暂停时间、 减少Full GC次数. 最关键参数:-Xms、 -Xmx 、-Xmn 、-XX:SurvivorRatio、-XX:MaxTenuringThreshold、-XX:PermSize、-XX:MaxPermSize.

java虚拟机的内存区域划分

- - CSDN博客推荐文章
         java虚拟机在执行java程序的过程中会把它所管理的内存划分成很多个不同的数据区域. 这些区域都有各自的用途,以及创建和销毁的时间,有的区域随着虚拟机进程的启动而存在,有些区域则是依赖用户线程的启动和结束而建立和销毁. Java虚拟机规范中把java虚拟机所管理的内存划分为以下几个区域.

深入Java虚拟机之内存优化

- - ITeye博客
前面一篇文章介绍了Java虚拟机的体系结构和内存模型,既然提到内存,就不得不说到内存泄露. 众所周知,Java是从C++的基础上发展而来的,而C++程序的很大的一个问题就是内存泄露难以解决,尽管Java的JVM有一套自己的垃圾回收机制来回收内存,在许多情况下并不需要java程序开发人员操太多的心,但也是存在泄露问题的,只是比C++小一点.

Java虚拟机(JVM)中的内存设置详解及优化

- - Java - 编程语言 - ITeye博客
JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制. 32位系统下,一般限制在1.5G~2G;64为操作系统对内存无限制. 我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m.

探秘Java虚拟机——内存管理与垃圾回收

- - 编程语言 - ITeye博客
探秘Java虚拟机——内存管理与垃圾回收. 本文主要是基于Sun JDK 1.6 Garbage Collector(作者:毕玄)的整理与总结,原文请读者在网上搜索. 1、Java虚拟机运行时的数据区. 2、常用的内存区域调节参数. -Xms:初始堆大小,默认为物理内存的1/64(<1GB);默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制.

Java 虚拟机 7:内存分配原则

- - ImportNew
对象的内存分配,往大的方向上讲,就是在堆上分配,少数情况下也可能会直接分配在老年代中,分配的规则并不是百分之百固定的,其细节决定于当前使用的是哪种垃圾收集器组合,当然还有虚拟机中与内存相关的参数. 垃圾收集器组合一般就是Serial+Serial Old和Parallel+Serial Old,前者是Client模式下的默认垃圾收集器组合,后者是Server模式下的默认垃圾收集器组合,文章使用对比学习法对比Client模式下和Server模式下同一条对象分配原则有什么区别.

Java虚拟机家族考

- ReadReply - 博客园新闻频道
  说起Java虚拟机,许多Java程序员都会潜意识地把它与Sun[1] HotSpot虚拟机等同看待,也许还有一些程序员会注意到BEA JRockit和IBM J9,但大多数人对JVM的认识都仅限于此了.   从1996年初Sun发布的JDK 1.0中所包含的Sun Classic VM算起,Java虚拟机已经发展了15个年头,沧海桑田一瞬间,15年转眼而过,这期间曾经涌现、湮灭过许多或经典或优秀或有特色的虚拟机实现,在《Java虚拟机专栏》的第1篇中,我们先暂且把代码与技术放下,一起来回顾一下Java虚拟机家族的发展轨迹和历史变迁.

文章: Java虚拟机家族考

- Haides - InfoQ中文站
说起Java虚拟机,许多Java程序员都会潜意识地把它与Sun HotSpot虚拟机等同看待,也许还有一些程序员会注意到BEA JRockit和IBM J9,但大多数人对JVM的认识都仅限于此了. 从1996年初Sun发布的JDK 1.0中所包含的Sun Classic VM算起,Java虚拟机已经发展了15个年头,沧海桑田一瞬间,15年转眼而过,这期间曾经涌现、湮灭过许多或经典或优秀或有特色的虚拟机实现,在《Java虚拟机专栏》的第1篇中,我们先暂且把代码与技术放下,一起来回顾一下Java虚拟机家族的发展轨迹和历史变迁.

历史篇:Java虚拟机家族考

- Guancheng(冠诚) - FenixSoft 3.0
  声明:本文为笔者原创,但首发于InfoQ中文站,详见文末声明.   说起Java虚拟机,许多Java程序员都会潜意识地把它与Sun[注1] HotSpot虚拟机等同看待,也许还有一些程序员会注意到BEA JRockit和IBM J9,但大多数人对JVM的认识都仅限于此了.   从1996年初Sun发布的JDK 1.0中所包含的Sun Classic VM算起,Java虚拟机已经发展了15个年头,沧海桑田一瞬间,15年转眼而过,这期间曾经涌现、湮灭过许多或经典或优秀或有特色的虚拟机实现,在《Java虚拟机专栏》的第1篇中,我们先暂且把代码与技术放下,一起来回顾一下Java虚拟机家族的发展轨迹和历史变迁.