- 浏览: 42914 次
- 性别:
- 来自: 上海
文章分类
最新评论
1. Jre的选用
如果安装JDK1.3那么安装程序一定会同时安装两套JRE。
一套位于 jdk\jre目录
一套位于program files\JavaSoft目录
JDK里面的工具几乎全是用java所写的,所以JDK本身就是Java应用程序,因此要用JDK附的工具来开发Java程序,也必须要自行附一套JRE才行。这就是JDK安装目录\jre下需要一套JRE的原因。
位于program files\下的那套JRE就是拿来执行我们自己写的java应用程序。
不过,两套中任何一套JRE 都可以拿来执行我们所撰写的Java 应用程序,
可是JDK 内附的开发工具在预设使用包装器(.exe) 来启动的情形下,都会自己去选用\jre 底下那套JRE。
2. 到底是执行哪一个java.exe
java xxx
当一台机器上有多个jvm可选择的时候,jvm的选择步骤:
1)当前目录有没有jre目录(不准确),
2)父目录下的jre子目录
3)注册表HEKY_LOCAL_MACHINE\SoftWare\Java\Java Runtime Environment\
所以当运行的是jdk\bin\java.exe的时候,用的jre是bin的父目录jdk下面的jre\
在system32目录 底下找不到JRE 目录,在c:\windows目录 也找不到JRE 目录的情况下,根据下一个逻辑,就是去查询注册表
java.exe在system32目录、program files\JavaSoft目录、jdk\jre目录都有一般先找的是system32下的。注册表注册的一般是program files\JavaSoft目录
运行java.exe找到了jre后有一个验证程序,verify.dll验证jre和java.exe的版本是否一致,如果不一致则会发生错误
一般把常用的工具档放到JDK目录\jre\lib\ext下,把有关安全机制的配置文件放到JDK目录\jre\lib\security下
3. 类加载器
每个类对java机来说,都是一个独立的动态联结函数库,只不过扩展名不是.dll或.so 而是.class
程序运行时需要的核心类库位于 jre\lib\rt.jar中
类加载器的作用就是把类从表态的硬盘 .class文件,复制一份到内存中,并做一此 始化工作
java.exe就是利用几个原则找到JRE后,把.class直接转交给JRE运行后便功成身退
3.1. classloader的两种载入方式:
1)pre-loading预先载入,载入基础类
2)load-on-demand按需求载入
只有实例化一个类时,该类才会被classloader载入,仅仅申明并不会载入
基础类库是预先加载的(pre-loading)
用户所写的一般类是按需加载的(load-on-demand)按需加载,依需求加载的优点是节省内存,但是仍有其缺点。举例来说,当程序第一次用到该类别的时候,系统就必须花一些额外的时间来加载该类别。
3.2. 使JAVA程序更有动态性的方法有两种
1)implicit隐式,即利用实例化才载入的特性来动态载入class
2)explicit显式方式,又分两种方式:
_ java.lang.Class的forName()方法
_ java.lang.ClassLoader的loadClass()方法
第一种方法: Class.forName() 加载类
一个是只有一个参数的:
public static Class forName(String className)
一个是需要三个参数的:
public static Class forName(String name, boolean initialize,ClassLoader loader)
这两个方法,最后都是连接到原生方法forName0(),
其宣告如下:
private static native Class forName0(String name,boolean initialize, ClassLoader loader) throws ClassNotFoundException;
只有一个参数的forName()方法,最后调用的是:
forName0(className, true,ClassLoader.getCallerClassLoader());
ClassLoader.getCallerClassLoader() 来取得加载呼叫他的类别所使用的类别加载器,是一个private 的方法,所以我们无法自行叫用。
具有三个参数的forName()方法,最后调用的是:
forName0(name, initialize, loader);
不管您使用的是new 来产生某类别的实例、或是使用只有一个参数的forName()方法,内部都隐含了”加载类别+呼叫静态初始化区块”的动作。
static块在什么时候执行?
1)当调用forName(String)载入class时执行,如果调用ClassLoader.loadClass并不会执行.forName(String,false,ClassLoader)时也不会执行.
2)如果载入Class时没有执行static块则在第一次实例化时执行.比如new ,Class.newInstance()操作
3)static块仅执行一次
第二种:直接使用ClassLoader 类别的loadClass() 方法来加载类
此方式只会把类加载至内存,并不会调用该类别的静态初始化区块,而必须等到第一次实例化该类别时,该类别的静态初始化区块才会被叫用。
这种情形与使用Class 类别的forName()方法时,第二个参数传入false 几乎是相同的结果。
Class类的实例.
4. Class类的实例.
_ Class类无法手工实例化,当载入任意类的时候自动创建一个该类对应的Class的实例,
_ 某个类的所有实例内部都有一个栏位记录着该类对应的Class的实例的位置.,
_ 每个java类对应的Class实例可以当作是类在内存中的代理人.所以当要获得类的信息(如有哪些类变量,有哪些方法)时,都可以让类对应的Class的实例代劳。
java的Reflection机制就大量的使用这种方法来实现
_ 每个java类都是由某个classLoader(ClassLoader的实例)来载入的,因此Class类别的实例中都会有栏位记录他的ClassLoader的实例,如果该栏位为null,则表示该类别是由bootstrap loader载入的(也称root laoder),bootstrap loader不是java所写成,所以没有实例.
5. Java启动过程
当我们在命令行输入java xxx.class 的时候,java.exe 根据我们之前所提过的逻辑找到了JRE(Java Runtime Environment) ,
接着找到位在JRE 之中的jvm.dll( 真正的Java 虚拟机),最后加载这个动态联结函式库,启动Java 虚拟机。
虚拟机一启动,会先做一些初始化的动作,比方说抓取系统参数等。一旦初始化动作完成之后,就会产生第一个类别加载器,
即所谓的Bootstrap Loader,Bootstrap Loader 是由C++ 所撰写而成(所以前面我们说,以Java的观点来看,逻辑上并不存在Bootstrap Loader 的类别实例,所以在Java 程序代码里试图印出其内容的时候,我们会看到的输出为null),这个Bootstrap Loader所做的初始工作中,
除了也做一些基本的初始化动作之外
最重要的就是加载定义在sun.misc 命名空间底下的Launcher.java 之中的ExtClassLoader,并设定其Parent 为null,代表其父加载器为Bootstrap Loader 。
然后Bootstrap Loader ,再要求加载定义于sun.misc 命名空间底下的Launcher.java 之中的AppClassLoader,并设定其Parent 为之前产生的ExtClassLoader 实例。
这里要请大家注意的是,Launcher$ExtClassLoader.class与Launcher$AppClassLoader.class 都是由Bootstrap Loader 所加载,所以Parent 和由哪个类别加载器加载没有关系,AppClassLoader 和ExtClassLoader 都是URLClassLoader 的子类别。
6. Classloader的加载路径
AppClassLoader:
由于它是URLClassLoader 的子类别,所以它们也应该有URL 作为搜寻类别档的参考AppClassLoader 所参考的URL 是从系统参数java.class.path 取出的字符串所决定,
而java.class.path 则是由我们在执行java.exe 时,
利用 –cp 或-classpath 或CLASSPATH 环境变量所决定。
搜寻路径:
在预设情况下,AppClassLoader的搜寻路径为”.”( 目前所在目录),
如果使用-classpath 选项(与-cp 等效),就可以改变AppClassLoader 的搜寻路径,
如果没有指定-classpath 选项,就会搜寻环境变量CLASSPATH 。
如果同时有CLASSPATH 的环境设定与-classpath 选项,则以-classpath 选项的内容为主,CLASSPATH 的环境设定与-classpath 选项两者的内容不会有加成的效果。
ExtClassLoader:
也有相同的情形,不过其搜寻路径是参考系统参数java.ext.dirs
Bootstrap Loader:
用sun.boot.class.path来搜寻类别的路径
特别注意:
_ 是否加载子目录
AppClassLoader 与Bootstrap Loader 不会递归式地搜寻这些位置下的其他路径或其他没有被指定的JAR 文件。
ExtClassLoader,所参考的系统参数是java.ext.dirs,意思是说,他会搜寻底下的所有JAR 文件以及classes 目录。
_ 启动后是否可以改变
AppClassLoader 与ExtClassLoader 在整个虚拟机之中只会存有一份,一旦建立了,其内部所参考的搜寻路径将不再改变,也就是说,即使我们在程序里利用System.setProperty() 来改变系统参数的内容,仍然无法更动AppClassLoader 与ExtClassLoader 的搜寻路径
委拖模型:类加载器有加载类别的需求时,会先请示其Parent 使用其搜寻路径帮忙加载,如果Parent 找不到,那么才由自己依照自己的搜寻路径搜寻类别。
7. JVM 的调试特性
详细输出
可以用 -verbose 命令行选项打开 IBM JVM 的详细输出。当某些事件发生的时候(例如,类装入时),详细输出会在控制台上显示信息。要想得到额外的类装入信息,可以用详细类输出。
可以用 -verbose:class 选项启动这个模式。
解释详细输出
详细输出列出已经打开的所有 JAR 文件,包括到这些 JAR 的完整路径。下面是一个示例:
...
[Opened D:\jre\lib\core.jar in 10 ms]
[Opened D:\jre\lib\graphics.jar in 10 ms]
...[size=small][/size]
ps补充:
在2004年9月,是Java最近的一次发布--J2SE 5.0(内部版本号1.5.0),代号\"Tiger\",现已提供公开下载。Tiger包含了从1996年发布1.0版本以来的最重大的更新,其中包括泛型支持、基本类型的自动装箱、改进的循环、枚举类型、格式化I/O及可变参数。
Java虚拟机(JVM)是一个软件规范,相关软件有责任遵守它,以运行编译为Java字节码的程序。JVM是一个抽象的计算机制,并独立于操作系统,具有编译后的程序体积小、可防止执行恶意代码等特点,其没有预先假设基于任何特定的实现技术,不管是硬件还是操作系统。通常我们有几个常用的JVM软件,其32位与64位版本性能有所不同,但它们都包括JIT编译器和垃圾回收功能(GC)。
JIT编译器从JDK 1.0.2开始就是JVM的一部分了,当时Java只是用于浏览器客户端动态效果显示的一种技术。JIT编译器实现了程序执行之前Java字节码到硬件机器码的动态翻译,其背后的思想在于,相比Java源代码,字节码更小也更容易编译,但付出的代价是需要在Java字节码编译为机器码时花上一点时间,但与直接把Java源代码编译为机器码相比,时间还是少得多的。在32位与64位的JVM中,相应的JIT在把Java字节码编译为最终的机器码时,所花的时间稍微有所不同,但还能进行一些优化;另外,在IBM与Sun这两个版本的客户端与服务端程序上,总体性能也会有所不同。 网管有家bitscn.net
垃圾回收是一种自动内存管理系统,它会收回对象不再需要使用的内存。从软件工程的角度来看,垃圾回收最大的一个好处就是--程序员不用再操心那些低级的内存管理细节了。同时,垃圾回收也去除了源代码中两个最大的bug--内存未释放(内存泄漏)与过早释放(指针崩溃)。内存回收在Java程序运行期间占了一个很重要的部分,因为它必须被经常执行以释放对象不再访问的Java堆。由于在32位与64位平台上,Java堆中的数据大小会有所变化,所以会因为32位与64位JVM的性能差异,导致相应垃圾回收的性能也会有所不同。
如果安装JDK1.3那么安装程序一定会同时安装两套JRE。
一套位于 jdk\jre目录
一套位于program files\JavaSoft目录
JDK里面的工具几乎全是用java所写的,所以JDK本身就是Java应用程序,因此要用JDK附的工具来开发Java程序,也必须要自行附一套JRE才行。这就是JDK安装目录\jre下需要一套JRE的原因。
位于program files\下的那套JRE就是拿来执行我们自己写的java应用程序。
不过,两套中任何一套JRE 都可以拿来执行我们所撰写的Java 应用程序,
可是JDK 内附的开发工具在预设使用包装器(.exe) 来启动的情形下,都会自己去选用\jre 底下那套JRE。
2. 到底是执行哪一个java.exe
java xxx
当一台机器上有多个jvm可选择的时候,jvm的选择步骤:
1)当前目录有没有jre目录(不准确),
2)父目录下的jre子目录
3)注册表HEKY_LOCAL_MACHINE\SoftWare\Java\Java Runtime Environment\
所以当运行的是jdk\bin\java.exe的时候,用的jre是bin的父目录jdk下面的jre\
在system32目录 底下找不到JRE 目录,在c:\windows目录 也找不到JRE 目录的情况下,根据下一个逻辑,就是去查询注册表
java.exe在system32目录、program files\JavaSoft目录、jdk\jre目录都有一般先找的是system32下的。注册表注册的一般是program files\JavaSoft目录
运行java.exe找到了jre后有一个验证程序,verify.dll验证jre和java.exe的版本是否一致,如果不一致则会发生错误
一般把常用的工具档放到JDK目录\jre\lib\ext下,把有关安全机制的配置文件放到JDK目录\jre\lib\security下
3. 类加载器
每个类对java机来说,都是一个独立的动态联结函数库,只不过扩展名不是.dll或.so 而是.class
程序运行时需要的核心类库位于 jre\lib\rt.jar中
类加载器的作用就是把类从表态的硬盘 .class文件,复制一份到内存中,并做一此 始化工作
java.exe就是利用几个原则找到JRE后,把.class直接转交给JRE运行后便功成身退
3.1. classloader的两种载入方式:
1)pre-loading预先载入,载入基础类
2)load-on-demand按需求载入
只有实例化一个类时,该类才会被classloader载入,仅仅申明并不会载入
基础类库是预先加载的(pre-loading)
用户所写的一般类是按需加载的(load-on-demand)按需加载,依需求加载的优点是节省内存,但是仍有其缺点。举例来说,当程序第一次用到该类别的时候,系统就必须花一些额外的时间来加载该类别。
3.2. 使JAVA程序更有动态性的方法有两种
1)implicit隐式,即利用实例化才载入的特性来动态载入class
2)explicit显式方式,又分两种方式:
_ java.lang.Class的forName()方法
_ java.lang.ClassLoader的loadClass()方法
第一种方法: Class.forName() 加载类
一个是只有一个参数的:
public static Class forName(String className)
一个是需要三个参数的:
public static Class forName(String name, boolean initialize,ClassLoader loader)
这两个方法,最后都是连接到原生方法forName0(),
其宣告如下:
private static native Class forName0(String name,boolean initialize, ClassLoader loader) throws ClassNotFoundException;
只有一个参数的forName()方法,最后调用的是:
forName0(className, true,ClassLoader.getCallerClassLoader());
ClassLoader.getCallerClassLoader() 来取得加载呼叫他的类别所使用的类别加载器,是一个private 的方法,所以我们无法自行叫用。
具有三个参数的forName()方法,最后调用的是:
forName0(name, initialize, loader);
不管您使用的是new 来产生某类别的实例、或是使用只有一个参数的forName()方法,内部都隐含了”加载类别+呼叫静态初始化区块”的动作。
static块在什么时候执行?
1)当调用forName(String)载入class时执行,如果调用ClassLoader.loadClass并不会执行.forName(String,false,ClassLoader)时也不会执行.
2)如果载入Class时没有执行static块则在第一次实例化时执行.比如new ,Class.newInstance()操作
3)static块仅执行一次
第二种:直接使用ClassLoader 类别的loadClass() 方法来加载类
此方式只会把类加载至内存,并不会调用该类别的静态初始化区块,而必须等到第一次实例化该类别时,该类别的静态初始化区块才会被叫用。
这种情形与使用Class 类别的forName()方法时,第二个参数传入false 几乎是相同的结果。
Class类的实例.
4. Class类的实例.
_ Class类无法手工实例化,当载入任意类的时候自动创建一个该类对应的Class的实例,
_ 某个类的所有实例内部都有一个栏位记录着该类对应的Class的实例的位置.,
_ 每个java类对应的Class实例可以当作是类在内存中的代理人.所以当要获得类的信息(如有哪些类变量,有哪些方法)时,都可以让类对应的Class的实例代劳。
java的Reflection机制就大量的使用这种方法来实现
_ 每个java类都是由某个classLoader(ClassLoader的实例)来载入的,因此Class类别的实例中都会有栏位记录他的ClassLoader的实例,如果该栏位为null,则表示该类别是由bootstrap loader载入的(也称root laoder),bootstrap loader不是java所写成,所以没有实例.
5. Java启动过程
当我们在命令行输入java xxx.class 的时候,java.exe 根据我们之前所提过的逻辑找到了JRE(Java Runtime Environment) ,
接着找到位在JRE 之中的jvm.dll( 真正的Java 虚拟机),最后加载这个动态联结函式库,启动Java 虚拟机。
虚拟机一启动,会先做一些初始化的动作,比方说抓取系统参数等。一旦初始化动作完成之后,就会产生第一个类别加载器,
即所谓的Bootstrap Loader,Bootstrap Loader 是由C++ 所撰写而成(所以前面我们说,以Java的观点来看,逻辑上并不存在Bootstrap Loader 的类别实例,所以在Java 程序代码里试图印出其内容的时候,我们会看到的输出为null),这个Bootstrap Loader所做的初始工作中,
除了也做一些基本的初始化动作之外
最重要的就是加载定义在sun.misc 命名空间底下的Launcher.java 之中的ExtClassLoader,并设定其Parent 为null,代表其父加载器为Bootstrap Loader 。
然后Bootstrap Loader ,再要求加载定义于sun.misc 命名空间底下的Launcher.java 之中的AppClassLoader,并设定其Parent 为之前产生的ExtClassLoader 实例。
这里要请大家注意的是,Launcher$ExtClassLoader.class与Launcher$AppClassLoader.class 都是由Bootstrap Loader 所加载,所以Parent 和由哪个类别加载器加载没有关系,AppClassLoader 和ExtClassLoader 都是URLClassLoader 的子类别。
6. Classloader的加载路径
AppClassLoader:
由于它是URLClassLoader 的子类别,所以它们也应该有URL 作为搜寻类别档的参考AppClassLoader 所参考的URL 是从系统参数java.class.path 取出的字符串所决定,
而java.class.path 则是由我们在执行java.exe 时,
利用 –cp 或-classpath 或CLASSPATH 环境变量所决定。
搜寻路径:
在预设情况下,AppClassLoader的搜寻路径为”.”( 目前所在目录),
如果使用-classpath 选项(与-cp 等效),就可以改变AppClassLoader 的搜寻路径,
如果没有指定-classpath 选项,就会搜寻环境变量CLASSPATH 。
如果同时有CLASSPATH 的环境设定与-classpath 选项,则以-classpath 选项的内容为主,CLASSPATH 的环境设定与-classpath 选项两者的内容不会有加成的效果。
ExtClassLoader:
也有相同的情形,不过其搜寻路径是参考系统参数java.ext.dirs
Bootstrap Loader:
用sun.boot.class.path来搜寻类别的路径
特别注意:
_ 是否加载子目录
AppClassLoader 与Bootstrap Loader 不会递归式地搜寻这些位置下的其他路径或其他没有被指定的JAR 文件。
ExtClassLoader,所参考的系统参数是java.ext.dirs,意思是说,他会搜寻底下的所有JAR 文件以及classes 目录。
_ 启动后是否可以改变
AppClassLoader 与ExtClassLoader 在整个虚拟机之中只会存有一份,一旦建立了,其内部所参考的搜寻路径将不再改变,也就是说,即使我们在程序里利用System.setProperty() 来改变系统参数的内容,仍然无法更动AppClassLoader 与ExtClassLoader 的搜寻路径
委拖模型:类加载器有加载类别的需求时,会先请示其Parent 使用其搜寻路径帮忙加载,如果Parent 找不到,那么才由自己依照自己的搜寻路径搜寻类别。
7. JVM 的调试特性
详细输出
可以用 -verbose 命令行选项打开 IBM JVM 的详细输出。当某些事件发生的时候(例如,类装入时),详细输出会在控制台上显示信息。要想得到额外的类装入信息,可以用详细类输出。
可以用 -verbose:class 选项启动这个模式。
解释详细输出
详细输出列出已经打开的所有 JAR 文件,包括到这些 JAR 的完整路径。下面是一个示例:
...
[Opened D:\jre\lib\core.jar in 10 ms]
[Opened D:\jre\lib\graphics.jar in 10 ms]
...[size=small][/size]
ps补充:
在2004年9月,是Java最近的一次发布--J2SE 5.0(内部版本号1.5.0),代号\"Tiger\",现已提供公开下载。Tiger包含了从1996年发布1.0版本以来的最重大的更新,其中包括泛型支持、基本类型的自动装箱、改进的循环、枚举类型、格式化I/O及可变参数。
Java虚拟机(JVM)是一个软件规范,相关软件有责任遵守它,以运行编译为Java字节码的程序。JVM是一个抽象的计算机制,并独立于操作系统,具有编译后的程序体积小、可防止执行恶意代码等特点,其没有预先假设基于任何特定的实现技术,不管是硬件还是操作系统。通常我们有几个常用的JVM软件,其32位与64位版本性能有所不同,但它们都包括JIT编译器和垃圾回收功能(GC)。
JIT编译器从JDK 1.0.2开始就是JVM的一部分了,当时Java只是用于浏览器客户端动态效果显示的一种技术。JIT编译器实现了程序执行之前Java字节码到硬件机器码的动态翻译,其背后的思想在于,相比Java源代码,字节码更小也更容易编译,但付出的代价是需要在Java字节码编译为机器码时花上一点时间,但与直接把Java源代码编译为机器码相比,时间还是少得多的。在32位与64位的JVM中,相应的JIT在把Java字节码编译为最终的机器码时,所花的时间稍微有所不同,但还能进行一些优化;另外,在IBM与Sun这两个版本的客户端与服务端程序上,总体性能也会有所不同。 网管有家bitscn.net
垃圾回收是一种自动内存管理系统,它会收回对象不再需要使用的内存。从软件工程的角度来看,垃圾回收最大的一个好处就是--程序员不用再操心那些低级的内存管理细节了。同时,垃圾回收也去除了源代码中两个最大的bug--内存未释放(内存泄漏)与过早释放(指针崩溃)。内存回收在Java程序运行期间占了一个很重要的部分,因为它必须被经常执行以释放对象不再访问的Java堆。由于在32位与64位平台上,Java堆中的数据大小会有所变化,所以会因为32位与64位JVM的性能差异,导致相应垃圾回收的性能也会有所不同。
发表评论
-
ClassLoader加载class的 流程
2009-11-17 15:39 1461java应用环境中不同的cla ... -
使用 XStream 在 JavaBean 与 XML/JSON 之间相互转换
2009-09-16 10:30 2425XML 和 JSON 是当今常用的两种数据描述与传输的格式,特 ... -
高效java异常处理机制
2008-12-04 14:44 3789Java 开 发人员可以做 ... -
排序算法java实现
2008-12-04 14:37 1231插入排序: 1. package org.rut. ... -
java程序性能优化
2008-12-01 09:55 675关键字: java 性能 一、避免在循环条件中使用复杂表达式 ... -
编写程序注意事项
2008-11-10 10:03 919是否符合代码格式化标准 是否有多余的import项 是否 ... -
spring任务调度 Quartz表达式
2008-11-05 15:48 1023关键字: quartz spring 字段 允许值 允许的特 ... -
request.getSession()无参,有参的区别
2008-11-05 15:40 1138API解释: getSession public ...
相关推荐
总之,Java与JVM的知识涉及广泛,从类加载机制到JVM内存模型,再到性能优化和故障排查,都是Java开发者必须掌握的核心技能。通过深入学习和实践,我们可以更好地驾驭Java应用程序,提高其稳定性和性能。
本篇文章将对JVM的基础知识进行总结,并探讨如何通过调整JVM参数来提升性能。 首先,我们需要了解JVM的主要组成部分:类装载器、运行时数据区、执行引擎、本地方法接口和本地方法库。其中,类装载器负责加载、验证...
**JVM(Java Virtual Machine)是Java程序运行的基础,它为Java代码提供了跨平台的运行环境。JVM的性能优化是提升Java应用效率的关键环节,涉及到内存管理、垃圾收集、线程调度等多个方面。** 一、JVM内存结构 1. *...
2. **多线程和JVM知识总结**:多线程是Java的一大特性,涉及线程同步、并发控制、死锁、线程池等概念;JVM(Java虚拟机)是Java程序运行的基础,涵盖内存模型、垃圾收集、类加载机制、性能优化等内容。 3. **...
本文根据《深入理解Java虚拟机》书籍内容及作者理解,总结了JVM相关的知识点,分享如下: 一、JVM内存区域 JVM在运行时,将内存空间分为若干个区域,主要包括方法区、堆内存、虚拟机栈、本地方法栈、程序计数器五...
Java虚拟机(JVM)是Java程序运行的基础,...了解并掌握这些JVM知识点,对于优化Java应用程序的性能、理解和解决运行时问题至关重要。在实际开发中,结合具体场景,灵活运用这些知识,能够提升程序效率,避免资源浪费。
JVM总结
JVM的基础知识涵盖了其内存模型、垃圾回收机制、线程模型等多个方面,下面将详细总结这些基础知识。 ### JVM内存模型 JVM内存模型主要可以分为线程共享区域和线程私有区域。 **线程共享区域** 1. 堆(Heap):...
JVM基本概念知识总结
本文档总结了JVM调优的基础知识和一些核心概念,旨在帮助开发者更好地掌握Java程序的性能优化。 首先,文档提到了Java中的数据类型分为基本类型和引用类型。基本类型的变量存储的是原始数据值,而引用类型的变量...
Java后端核心知识总结:JVM篇 Java后端核心知识总结:并发编程篇 Java后端核心知识总结:MySQL篇 Java后端核心知识总结:Redis Java后端核心知识总结:RabbitMQ Java后端核心知识总结:Kafak Java后端核心知识总结:...
JVM知识点总结,最全思维导图,互联网大厂面试必备
总结来说,理解和掌握JVM内存区域的划分以及如何避免内存溢出是Java开发中至关重要的知识点,这有助于优化程序性能和解决运行时的内存问题。通过深入学习JVM的内存管理机制,开发者可以更好地控制和调优Java应用程序...
### Java-JVM调优总结 #### 一、引言 在现代软件开发中,Java 作为一种广泛使用的编程语言,其应用程序的性能优化至关重要。而 JVM(Java Virtual Machine)作为 Java 程序运行的基础环境,对其进行合理的调优可以...
以下是对JVM核心知识点的详细梳理和面试题的总结: 1. **内存结构** - **堆(Heap)**:所有线程共享的内存区域,用于存储对象实例。堆分为新生代和老年代。 - **新生代** 包括Eden区、Survivor区(from和to)。...
JVM详细的知识点总结,思维导图 1.类加载器子系统 2.Hotspot的内存详情 3.HotSpot虚拟机对象探秘 4.垃圾收集器
了解和掌握这些JVM相关知识,对于优化Java应用的性能、避免内存泄漏以及解决问题具有重要意义。在实际工作中,开发者可以根据应用程序的需求,通过调整JVM参数来达到最佳的运行效果。同时,利用各种监控工具,如...
JVM(Java虚拟机)是Java程序的...JVM入门总结涵盖了从JVM基础到高级垃圾回收的各个方面。掌握了这些知识点,可以帮助我们更好地了解Java程序的运行机制,优化内存使用,以及合理选择垃圾回收策略,从而提升程序性能。
在深入讨论JVM(Java虚拟机)调优之前,我们有必要先了解一下虚拟机的基本概念和堆栈...通过上述的分析和总结,我们可以得出,JVM调优是一个涉及多方面知识的复杂过程,需要开发者具备扎实的理论基础和丰富的实践经验。