虚拟机运行一个java程序但是通过ip端口无法访问到

转载

mob6454cc777577 2024-09-10 06:53:17

文章标签 JVM 类装载器 Java 文章分类 Java 后端开发

参考文档:

深入Java虚拟机(书本)

511.cto: http://book.51cto.com/art/201203/321001.htm

Java虚拟机通常是指: 1 抽象规范

2 一个具体的虚拟机的实现(就是规范的是实现)

3. 一个运行中的虚拟机实例

1:抽象规范仅仅是一个概念, ,这个规范的实现需要有人实现,(我想是说的open JDK, Oracle JDK吧)

2 当运行一个java程序的时候, 相当于运行一个java虚拟机.因为这个程序的运行需要java虚拟机

所以在一下的探究中,请大家联系上下文,去理解我们指的虚拟机是” 抽象规范”? “具体的虚拟机的实现(就是规范的是实现”? 还是”运行中的虚拟机实例”

Java虚拟机的职责: 负责运行一个java程序

如果有多个java程序在同一台机子上运行. 那么会有三个java虚拟机实例(又可以说是3个java虚拟机) , 每个程序都运行在自己的虚拟机中(这说明: 程序之间的数据不能直接的交换)

在java虚拟机的内部有两种线程, 一种是守护线程 ,另一种是非守护线程 . 守护线程是由虚拟机自己使用的, 而 java程序中的初始线程main() , 是一个非守护线程

当所有的非守护线程死亡的时候, 这个虚拟机才会退出

从一张图说起:

虚拟机的体系结构图:

What 类装载器:

会根据给定的全限来装入类或者是接口

在Java中，类装载器把一个类装入JVM中，要经过以下步骤：

1．装载：查找和导入Class文件；

2．链接：执行校验、准备和解析步骤，其中解析步骤是可以选择的：

a）校验：检查载入Class文件数据的正确性；

b）准备：给类的静态变量分配存储空间；

c）解析：将符号引用转成直接引用；

3．初始化：对类的静态变量、静态代码块执行初始化工作。

类装载工作由ClassLoader及其子类负责，ClassLoader是一个重要的Java运行时系统组件，它负责在运行时查找和装入Class字节码文件。JVM在运行时会产生三个ClassLoader：根装载器、ExtClassLoader（扩展类装载器）和AppClassLoader（系统类装载器）。其中，根装载器不是ClassLoader的子类，它使用C++编写，因此我们在Java中看不到它，根装载器负责装载JRE的核心类库，如JRE目标下的rt.jar、charsets.jar等。ExtClassLoader和AppClassLoader都是ClassLoader的子类。其中ExtClassLoader负责装载JRE扩展目录ext中的JAR类包；AppClassLoader负责装载Classpath路径下的类包。

这三个类装载器之间存在父子层级关系，即根装载器是ExtClassLoader的父装载器，ExtClassLoader是AppClassLoader的父装载器。默认情况下，使用AppClassLoader装载应用程序

代码实例

结果:

从结果中看出

这三个类的确存在父子关系,而且默认是AppClassLoader呀.

当前的ClassLoader是AppClassLoader，父ClassLoader是ExtClassLoader，祖父ClassLoader是根类装载器，因为在Java中无法获得它的句柄，所以仅返回null。

JVM装载类时使用"全盘负责委托机制"，"全盘负责"是指当一个ClassLoader装载一个类的时，除非显式地使用另一个ClassLoader，该类所依赖及引用的类也由这个ClassLoader载入；"委托机制"是指先委托父装载器寻找目标类，只有在找不到的情况下才从自己的类路径中查找并装载目标类。这一点是从安全角度考虑的，试想如果有人编写了一个恶意的基础类（如java.lang.String）并装载到JVM中将会引起多么可怕的后果。但是由于有了"全盘负责委托机制"，java.lang.String永远是由根装载器来装载的，这样就避免了上述事件的发生。

实战经验

但凡Java的开发者，想必遇到过java.lang.NoSuchMethodError的错误信息吧。究其源，这个错误基本上都是由JVM的"全盘负责委托机制"引发的问题：因为在类路径下放置了多个不同版本的类包，如commons-lang 2.x.jar和commons-lang3.x.jar都位于类路径中，代码中用到了commons-lang3.x类的某个方法，而这个方法在commons-lang2.x中并不存在，JVM加载类时碰巧又从commons-lang 2.x.jar中加载类，运行时就会抛出NoSuchMethodError的错误。

这种问题的排查是比较棘手的，特别是在Web应用的情况下，可作为类路径的系统目录比较多，特别在类包众多时，情况尤其复杂：你不知道JVM到底从哪个类包中加载类文件。不过笔者有一个一般人不告诉的易用小工具，现奉献出来：

在光盘根路径下有一个srcAdd.jsp的程序，你把它放到Web应用的根路径下，通过如下方式即可查看JVM从哪个类包加载指定类：

http://localhost/srcAdd.jsp?className=java.net.URL

ClassLoader重要方法

在Java中，ClassLoader是一个抽象类，位于java.lang包中。下面对该类的一些重要接口方法进行介绍：

Class loadClass(String name)

name参数指定类装载器需要装载类的名字，必须使用全限定类名，如com.baobaotao. beans.Car。该方法有一个重载方法loadClass(String name ,boolean resolve)，resolve参数告诉类装载器是否需要解析该类。在初始化类之前，应考虑进行类解析的工作，但并不是所有的类都需要解析，如果JVM只需要知道该类是否存在或找出该类的超类，那么就不需要进行解析。

Class defineClass(String name, byte[] b, int off, int len)

将类文件的字节数组转换成JVM内部的java.lang.Class对象。字节数组可以从本地文件系统、远程网络获取。name为字节数组对应的全限定类名。

Class findSystemClass(String name)

从本地文件系统载入Class文件，如果本地文件系统不存在该Class文件，将抛出ClassNotFoundException异常。该方法是JVM默认使用的装载机制。

Class findLoadedClass(String name)

调用该方法来查看ClassLoader是否已装入某个类。如果已装入，那么返回java.lang.Class对象，否则返回null。如果强行装载已存在的类，将会抛出链接错误。

ClassLoader getParent()

获取类装载器的父装载器，除根装载器外，所有的类装载器都有且仅有一个父装载器，ExtClassLoader的父装载器是根装载器，因为根装载器非Java编写，所以无法获得，将返回null。

除JVM默认的三个ClassLoader以外，可以编写自己的第三方类装载器，以实现一些特殊的需求。类文件被装载并解析后，在JVM内将拥有一个对应的java.lang.Class类描述对象，该类的实例都拥有指向这个类描述对象的引用，而类描述对象又拥有指向关联ClassLoader的引用，如图3-4所示。

每一个类在JVM中都拥有一个对应的java.lang.Class对象，它提供了类结构信息的描述。数组、枚举、注解以及基本Java类型（如int、double等），甚至void都拥有对应的Class对象。Class没有public的构造方法。Class对象是在装载类时由JVM通过调用类装载器中的defineClass()方法自动构造的。