jvm装入原理以及其启动参数

在我们运行和调试java程序的时候,经常会提到一个jvm的概念.jvm是java程序运行的环境,但是他同时一个操作系统的一个应用程序一个进程,因此他也有他自己的运行的生命周期,也有自己的代码和数据空间.
首先来说一下jdk这个东西,不管你是初学者还是高手,是j2ee程序员还是j2se程序员,jdk总是在帮我们做一些事情.我们在了解java之前首先 大师们会给我们提供说jdk这个东西.它在java整个体系中充当着什么角色呢?我很惊叹sun大师们设计天才,能把一个如此完整的体系结构化的如此完 美.jdk在这个体系中充当一个生产加工中心,产生所有的数据输出,是所有指令和战略的执行中心.本身它提供了java的完整方案,可以开发目前java 能支持的所有应用和系统程序.这里说一个问题,大家会问,那为什么还有j2me,j2ee这些东西,这两个东西目的很简单,分别用来简化各自领域内的开发 和构建过程.jdk除了jvm之外,还有一些核心的API,集成API,用户工具,开发技术,开发工具和API等组成
好了,废话说了那么多,来点于主题相关的东西吧.jvm在整个jdk中处于最底层,负责于操作系统的交互,用来屏蔽操作系统环境,提供一个完整的java 运行环境,因此也就虚拟计算机. 操作系统装入jvm是通过jdk中java.exe来完成,通过下面4步来完成jvm环境.
1.创建jvm装载环境和配置
2.装载jvm.dll
3.初始化jvm.dll并挂界到JNIENV(JNI调用接口)实例
4.调用JNIEnv实例装载并处理class类。
一.jvm装入环境,jvm提供的方式是操作系统的动态连接文件.既然是文件那就一个装入路径的问题,java是怎么找这个路径的呢?当你在调用java test的时候,操作系统会在path下在你的java.exe程序,java.exe就通过下面一个过程来确定jvm的路径和相关的参数配置了.下面基 于windows的实现的分析.
  首先查找jre路径,java是通过GetApplicationHome api来获得当前的java.exe绝对路径,c:/j2sdk1.4.2_09/bin/java.exe,那么它会截取到绝对路径c:/ j2sdk1.4.2_09/,判断c:/j2sdk1.4.2_09/bin/java.dll文件是否存在,如果存在就把c:/ j2sdk1.4.2_09/作为jre路径,如果不存在则判断c:/j2sdk1.4.2_09/jre/bin/java.dll是否存在,如果存在 这c:/j2sdk1.4.2_09/jre作为jre路径.如果不存在调用GetPublicJREHome查HKEY_LOCAL_MACHINE/ Software/JavaSoft/Java Runtime Environment/“当前JRE版本号”/JavaHome的路径为jre路径。
  然后装载jvm.cfg文件JRE路径+/lib+/ARCH(CPU构架)+/jvm.cfgARCH(CPU构架)的判断是通过 java_md.c中GetArch函数判断的,该函数中windows平台只有两种情况:WIN64的‘ia64’,其他情况都为‘i386’。以我的 为例:C:/j2sdk1.4.2_09/jre/lib/i386/jvm.cfg.主要的内容如下:
-client KNOWN
-server KNOWN
-hotspot ALIASED_TO -client
-classic WARN
-native ERROR
-green ERROR
在我们的jdk目录中jre/bin/server和jre/bin/client都有jvm.dll文件存在,而java正是通过jvm.cfg配置文 件来管理这些不同版本的jvm.dll的.通过文件我们可以定义目前jdk中支持那些jvm,前面部分(client)是jvm名称,后面是参数, KNOWN表示jvm存在,ALIASED_TO表示给别的jvm取一个别名,WARN表示不存在时找一个jvm替代,ERROR表示不存在抛出异常.在 运行java XXX是,java.exe会通过CheckJvmType来检查当前的jvm类型,java可以通过两种参数的方式来指定具体的jvm类型,一种按照 jvm.cfg文件中的jvm名称指定,第二种方法是直接指定,它们执行的方法分别是“java -J”、“java -XXaltjvm=”或“java -J-XXaltjvm=”。如果是第一种参数传递方式,CheckJvmType函数会取参数‘-J’后面的jvm名称,然后从已知的jvm配置参数中 查找如果找到同名的则去掉该jvm名称前的‘-’直接返回该值;而第二种方法,会直接返回“-XXaltjvm=”或“-J-XXaltjvm=”后面的 jvm类型名称;如果在运行java时未指定上面两种方法中的任一一种参数,CheckJvmType会取配置文件中第一个配置中的jvm名称,去掉名称 前面的‘-’返回该值。CheckJvmType函数的这个返回值会在下面的函数中汇同jre路径组合成jvm.dll的绝对路径。如果没有指定这会使用 jvm.cfg中第一个定义的jvm.可以通过set _JAVA_LAUNCHER_DEBUG=1在控制台上测试.
最后获得jvm.dll的路径,JRE路径+/bin+/jvm类型字符串+/jvm.dll就是jvm的文件路径了,但是如果在调用java程序时用-XXaltjvm=参数指定的路径path,就直接用path+/jvm.dll文件做为jvm.dll的文件路径.
  二:装载jvm.dll
通过第一步已经找到了jvm的路径,java通过LoadJavaVM来装入jvm.dll文件.装入工作很简单就是调用windows API函数:
LoadLibrary装载jvm.dll动态连接库.然后把jvm.dll中的导出函数JNI_CreateJavaVM和 JNI_GetDefaultJavaVMInitArgs挂接到InvocationFunctions变量的CreateJavaVM和 GetDefaultJavaVMInitArgs函数指针变量上。jvm.dll的装载工作宣告完成。
  三:初始化jvm,获得本地调用接口,这样就可以在java中调用jvm的函数了.调用InvocationFunctions->CreateJavaVM也就是jvm中JNI_CreateJavaVM方法获得JNIEnv结构的实例.
  四:运行java程序.
java程序有两种方式一种是jar包,一种是class. 运行jar,java -jar XXX.jar运行的时候,java.exe调用GetMainClassName函数,该函数先获得JNIEnv实例然后调用java类 java.util.jar.JarFileJNIEnv中方法getManifest()并从返回的Manifest对象中取 getAttributes("Main-Class")的值即jar包中文件:META-INF/MANIFEST.MF指定的Main-Class的 主类名作为运行的主类。之后main函数会调用java.c中LoadClass方法装载该主类(使用JNIEnv实例的FindClass)。main 函数直接调用java.c中LoadClass方法装载该类。如果是执行class方法。main函数直接调用java.c中LoadClass方法装载 该类。

 

然后main函数调用JNIEnv实例的GetStaticMethodID方法查找装载的class主类中
“public static void main(String[] args)”方法,并判断该方法是否为public方法,然后调用JNIEnv实例的
CallStaticVoidMethod方法调用该java类的main方法。

JVM的启动参数:
     一、标准参数
    1.-server 
      -client
        虚拟机服务器模式/客户机模式,使 用server模式可以提高性能,启动比client模式慢,长期运行则比client模式快。当该参数不指定时,虚拟机启动检测主机是否为服务器,如果 是则以server模式启动,否则以client模式启动,J2SE5.0检测的根据是至少2个CPU和最低2GB内存
    2.-agentlib:<lib-name>=<options>
      -agentpath:<lib-path>=<options>
       本地类库加载,当你的部分类包含一些本地方法时,需要自己编写本地代码并位于操作系统加载共享包(dll)的路径上,如果你不喜欢将该包放在操作系统识别 的加载上,则可以通过指定这个参数来加载自己的本地共享包(dll)。不同之处在于-agentlib中仅指定包名,根据操作系统的不同虚拟机在一定路径 上搜索该包,譬如对于windows平台虚拟机在PATH路径上搜索该包,而lib-path则是指定全路径,例如
     -agentlib:hprof  在windows平台虚拟机会在启动时到PATH路径上搜索hprof.dll并加载
     虚拟机在加载代理包之后有一个启动的操作(详细参见JDK参考),<options>指的是代理包的启动参数
     3.-classpath classpath
       -c classpath
     指定类路径,系统应用类加载器(ClassLoader)会到该路径下加载类
     4.-Dproperty=value
     设置系统属性,可以通过System.getProperty(property)获得
     5.-enableassertions[:<package name>"..." | :<class name> ]
       -ea[:<package name>"..." | :<class name> ]
       -disableassertions[:<package name>"..." | :<class ; ]
       -da[:<package name>"..." | :<class name> ] 
        启用和停用断言,默认是停用断言。断言指的是从JDK1.4开始在支持的关键字assert,assert(booleanvalue),当 booleanvalue为false时,抛出java.lang.AssertionError,必须指出的是,代码编译必须是1.4及其以上顺从的, 即编译时使用如下参数
       java -source 1.4
       一般仅在开发阶段启用断言,而在运行阶段不使用
       其使用包括如下几种情况
       java -ea    //启动断言
       java -eakname...  //在包pkname及其子包下起用断言
       java -eakname.classname  //对类 pkname.classname启用断言
       停用断言与启用设置类似
     6.-enablesystemassertions
       -esa 
       -disablesystemassertions
       -dsa 
       启用和停用系统类断言
     7.-jar
       运行包含在一个jar包里的程序,一般在jar包的/META-INF/MANIFEST.MF文件中指定Main-Class值为要运行的主函数,譬如                 Main-Class:ayufox.ejb3.Test
     8.-javaagent:<classname>[<=options>]
       加载java语言代理,该功能是JDK5新增加的,可以通过该设置在JVM运行主函数(main)之前做一些预处理工作,其中classname中必须包含有静态方法
       public static void premain(String agentArgs, Instrumentation inst) { ... }
       上面的options即是传入该函数的代理参数agentArgs,关于Instrumentation详细参见包java.lang.instrument
     9.-verbose
       -verbose:class
       -verbose:gc
       -verbose:jni 
       在运行时
       class:将类加载情况在控制台中打印出来
       gc:将虚拟机的垃圾回收事件信息打印
       jni:放本地方法调用信息打印
       -verbose与-verbose:class一样
     10.-version
        -showversion
        显示版本信息,不同在于第一种显示版本后虚拟机结束退出
     11.-?
        -help
        显示帮助信息并退出 
     12.-X
        显示非标准参数(见下面介绍)并退出
     二、非标准参数(以-X开头)
     1.-Xint
        所有字节码以解析模式运行。第一代虚拟机即是以这种方式运行,由于需要Java解析器解析运行,所以效率比较低;第二代虚拟机则采用将字节码编译成本地代 码的方式,效率大大提高;第三代虚拟机也叫自适应(HotSpot)虚拟机,通过监测代码的执行情况检测出代码被频繁执行的部分,将其尽量优化成本地代码 方式运行,而对于普通部分,则采用解析的模式运行。
     2.-Xbatch
       禁止后台编译,一般HotSpot虚拟机在检测到一段代码为频繁执行代码需要将其编译成本地代码时,会启动一个后台线程完成这个工作,而同时采用解析的方式继续运行字节码。如果设置了该参数,则会停止继续执行字节码,先将其编译成本地代码,然后再继续执行。
     3.-Xdebug       
       -Xnoagent
       -Xrun
       -Xrunjdwp
     启用调试模式,见前面的《利用JPDA构建调试平台》这篇文章,后面将在一个独立的文章中详细介绍
     4.-Xbootclasspath:bootclasspath  
       -Xbootclasspath/path  
       -Xbootclasspath/path  
       设置启动根Classpath,即使启动类加载器将在何处加载对象,关于类启动加载器,参见《JVM类加载器体系结构》说明,分号后面的值指定路径,以分 号隔开。其区别在于,-Xbootclasspath:bootclasspath将新的根加载路径覆盖默认的路径(/jre/lib/rt.jar), -Xbootclasspath/path将新的根加载路径和原有的根加载路径相结合,-Xbootclaspath/path将新的根加载路径与原有的根加载路径相结合,加载类时优先搜索该加载路径
     5.-Xcheck:jni
       对本地调用(JNI)采用更严格的检测方式,在进行JNI调用之前检测数据和传入参数,如果碰到不合法的数据则强制结束掉虚拟机,对运行性能有损害
     6.-Xfuture
       对类格式(class文件格式)采用更严格的检测方式,以便向后兼容,最好在开发时采用该参数
     7.-Xnoclassgc
       不使用垃圾回收
     8.-Xloggc:file
       与-verbose:gc功能一样,不同在于-Xloggc:file将信息记录到一个文件,而-verbose:gc将其输出到控制台
     9.-Xincgc
       -Xmsn
       -Xmxn
       -Xssn  
      跟内存分配和垃圾回收相关,-Xincgc表示采用渐进式垃圾回收,-Xmsn设置初始内存池大小,-Xmxn表示内存池允许的最大大小,-Xssn是线程栈大小,n是要设置的值,必须是1024的倍数,譬如
      -Xms6291456 -Xmx83886080
      -Xms6144k -Xmx81920k
      -Xms6m -Xmx80m
      该部分对虚拟机的性能非常重要,在后面将有独立的篇章详细介绍
     10.-Xprof
        -Xrunhprof[:help][:<suboption>=<value>,...]
      在运行时剖析运行情况,并将剖析结果打印到控制台,其中后一个可以指定特定剖析对象,譬如cpu,堆(heap)等,可以运行java -Xrunhprof:help获得可以剖析的对象和取值
      11.-Xrs
      减少JVM对操作系统信号量的使用,J2SE1.3.1开始引入。
      SUN 在J2SE1.3.0中增加了Java应用程序关闭时的回调钩子(Hook),以便当JVM意外终止时用户可以做一些资源清除工作。JVM监视控制台事件 以实现JVM意外终止时的回调。JVM明确地注册了一个控制台控制处理器,当JVM接收到CTRL_C_EVENT,  CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, 或CTRL_SHUTDOWN事件时,该处理器介入关闭回掉钩子 (HOOK)的处理。
      如果虚拟机以服务的方式运行(譬如WEB服务器)当其收到CTRL_LOGOFF_EVENT事件,由于系统并 不会因此终止JVM进程,故JVM不可以进行终止的操作,然而这与如上产生了冲突(不结束却又调用关闭回调钩子),为了避免这个问题,从 J2SE1.3.1使用-Xrs以使JVM不再监测控制台事件。

  JVM内存的设置的原理

默认的java虚拟机的大小比较小,在对大数据进行处理时java就会报错:java.lang.OutOfMemoryError。
设置jvm内存的方法,对于单独的.class,可以用下面的方法对Test运行时的jvm内存进行设置。
java -Xms64m -Xmx256m Test
-Xms是设置内存初始化的大小
-Xmx是设置最大能够使用内存的大小(最好不要超过物理内存大小)
在weblogic中,可以在startweblogic.cmd中对每个domain虚拟内存的大小进行设置,默认的设置是在commEnv.cmd里面。


  JVM内存的调优

1. Heap设定与垃圾回收Java Heap分为3个区,Young,Old和Permanent。Young保存刚实例化的对象。当该区被填满时,GC会将对象移到Old区。Permanent区则负责保存反射对象,本文不讨论该区。JVM的Heap分配可以使用-X参数设定,

-Xms
初始Heap大小
-Xmx
java heap最大值
-Xmn
young generation的heap大小

JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时,遍历Heap,将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn,不能将-Xms的值设的过大,因为第二个线程被迫运行会降低JVM的性能。 为什么一些程序频繁发生GC?有如下原因: l       程序内调用了System.gc()或Runtime.gc()。 l       一些中间件软件调用自己的GC方法,此时需要设置参数禁止这些GC。 l       Java的Heap太小,一般默认的Heap值都很小。 l       频繁实例化对象,Release对象。此时尽量保存并重用对象,例如使用StringBuffer()和String()。       如果你发现每次GC后,Heap的剩余空间会是总空间的50%,这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。 经验之谈: 1.Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC,最好让-Xmn值约等于-Xmx的1/3[2]。 2.一个GUI程序最好是每10到20秒间运行一次GC,每次在半秒之内完成[2]。 注意: 1.增加Heap的大小虽然会降低GC的频率,但也增加了每次GC的时间。并且GC运行时,所有的用户线程将暂停,也就是GC期间,Java应用程序不做任何工作。 2.Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值,因为Java为其他任务分配内存,例如每个线程的Stack等。 2.Stack的设定 每个线程都有他自己的Stack。
-Xss
每个线程的Stack大小

Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小,例如-Xss1024K。如果Stack太小,也会导致Stack溢漏。 3.硬件环境 硬件环境也影响GC的效率,例如机器的种类,内存,swap空间,和CPU的数量。 如果你的程序需要频繁创建很多transient对象,会导致JVM频繁GC。这种情况你可以增加机器的内存,来减少Swap空间的使用[2]。 4.4种GC 第一种为单线程GC,也是默认的GC。,该GC适用于单CPU机器。 第二种为Throughput GC,是多线程的GC,适用于多CPU,使用大量线程的程序。第二种GC与第一种GC相似,不同在于GC在收集Young区是多线程的,但在Old区和第一种一样,仍然采用单线程。-XX:+UseParallelGC参数启动该GC。 第三种为Concurrent Low Pause GC,类似于第一种,适用于多CPU,并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时,运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。 第四种为Incremental Low Pause GC,适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时,回收一部分Old区对象。-Xincgc参数启动该GC。 4种GC的具体描述参见[3]。 参考文章:1. JVM Tuning. http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp#garbage-collection

3. Tuning Garbage Collection with the 1.4.2 JavaTM Virtual Machine .
 
  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值