本文目录一览：
- 1、java虚拟机工作原理？
- 2、Java虚拟机的堆，栈，堆栈如何去理解
- 3、jvm中虚拟机栈描述正确的是
- 4、怎样使JAVA栈内存快速溢出
- 5、怎么把Java运行时的虚拟机参数的栈大小调到256K以上
- 6、如何检查和解决java虚拟机内存溢出的问题
java虚拟机工作原理？
从宏观上介绍一下Java虚拟机的工作原理。从最初编写的Java源文件（.java文件）是如何一步步执行的，如下图所示，首先Java源文件经过前端编译器（javac或ECJ）将.java文件编译为Java字节码文件，然后JRE加载Java字节码文件，载入系统分配给JVM的内存区，然后执行引擎解释或编译类文件，再由即时编译器将字节码转化为机器码。主要介绍下图中的类加载器和运行时数据区两个部分。
（1）类加载指将类的字节码文件（.class）中的二进制数据读入内存，将其放在运行时数据区的 *** 区内，然后在堆上创建java.lang.Class对象，封装类在 *** 区内的数据结构。类加载的最终产品是位于堆中的类对象，类对象封装了类在 *** 区内的数据结构，并且向JAVA程序提供了访问 *** 区内数据结构的接口。如下是类加载器的层次关系图。
启动类加载器（BootstrapClassLoader）：在JVM运行时被创建，负责加载存放在JDK安装目录下的jre\lib的类文件，或者被-Xbootclasspath参数指定的路径中，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类无法被JAVA程序直接引用。
扩展类加载器（Extension ClassLoader）：该类加载器负责加载JDK安装目录下的\jre\lib\ext的类，或者由java.ext.dirs系统变量指定路径中的所有类库，开发者也可以直接使用扩展类加载器。
应用程序类加载器（AppClassLoader）：负责加载用户类路径（Classpath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有定义过自己的类加载器，该类加载器为默认的类加载器。
用户自定义类加载器（User ClassLoader）：JVM自带的类加载器是从本地文件系统加载标准的java class文件，而自定义的类加载器可以做到在执行非置信代码之前，自动验证数字签名，动态地创建符合用户特定需要的定制化构建类，从特定的场所（数据库、 *** 中）取得java class。
注意如上的类加载器并不是通过继承的方式实现的，而是通过组合的方式实现的。而JAVA虚拟机的加载模式是一种委派模式，如上图中的1-7步所示。下层的加载器能够看到上层加载器中的类，反之则不行。类加载器可以加载类但是不能卸载类。说了一大堆，还是感觉需要拿点代码说事。
首先先定义自己的类加载器MyClassLoader，继承自ClassLoader，并覆盖了父类的findClass(String name) *** ，如下：
利用定义的类加载器加载指定的字节码文件，如通过MyClassLoader加载C:\\Users\\Administrator\\下的Test.class字节码文件，代码如下所示：
（2）运行时数据区
字节码的加载之一步，其后分别是认证、准备、解析、初始化，那么这些步骤又具体做了哪些工作，如下图所示：
（3）如下将介绍运行时数据区，主要分为 *** 区、Java堆、虚拟机栈、本地 *** 栈、程序计数器。其中 *** 区和Java堆一样，是各个线程共享的内存区域，而虚拟机栈、本地 *** 栈、程序计数器是线程私有的内存区。
Java堆：Java堆是Java虚拟机所管理的内存中更大的一块，被进程的所有线程共享，在虚拟机启动时被创建。该区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存，随着JIT编译器的发展与逃逸分支技术逐渐成熟，栈上分配、标量替换等优化技术使得对象在堆上的分配内存变得不是那么“绝对”。Java堆是垃圾收集器管理的主要区域。由于现在的收集器基本都采用分代收集算法，所以Java堆中还可以分为老年代和新生代(Eden、From Survivor、To Survivor)。根据Java虚拟机规范，Java堆可以处于物理上不连续的内存空间，只要逻辑上连续即可。该区域的大小可以通过-Xmx和-Xms参数来扩展，如果堆中没有内存完成实例分配，并且堆也无法扩展，将会抛出OutOfMemoryError异常。
*** 区：用于存储被Java虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。不同于Java堆的是，Java虚拟机规范对 *** 区的限制非常宽松，可以选择不实现垃圾收集。但并非数据进入了 *** 区就“永久”存在了，这区域内存回收目标主要是针对常量池的回收和对类型的卸载。如果该区域内存不足也会抛出OutOfMemoryError异常。
常量池：这个名词可能大家也经常见，是 *** 区的一部分。Class文件除了有类的版本、字段、 *** 、接口等描述信息外，还有一项信息就是常量池，用于存放编译期生成的各种字面量和符号引用。Java虚拟机运行期间，也可能将新的常量放入常量池（如String类的intern() *** ）。
虚拟机栈：线程私有，生命周期与线程相同。虚拟机栈描述的是Java *** 执行的内存模型：每个 *** 在执行时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、 *** 出口等信息。每个 *** 从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。如果请求的站深度大于虚拟机所允许的深度，将抛出StackOverflowError异常，虚拟机栈在动态扩展时如果无法申请到足够的内存，就会抛出OutOfMemoryError异常。
过最简单的一段代码解释一下，程序在运行时数据区个部分的变化情况。
（4）通过编译器将Test.java文件编译为Test.class，利用javap -verbose Test.class对编译后的字节码进行分析，如下图所示：
（5）看看运行时数据区的变化：
Java虚拟机的堆，栈，堆栈如何去理解
JVM线程堆栈是一个给定时间的快照，它能向你提供所有被创建出来的Java线程的完整清单.每一个被发现的Java线程都会给你如下信息:–线程的名称；经常被中间件厂商用来识别线程的标识，一般还会带上被分配的线程池名称以及状态(运行，阻塞等等.)–线程类型优先级，例如:daemonprio=3**中间件程序一般以后台守护的形式创建他们的线程，这意味着这些线程是在后台运行的；它们会向它们的用户提供服务，例如：向你的JavaEE应用程序**–Java线程ID，例如:tid=0x000000011e52a800**这是通过java.lang.Thread.getId()获得的Java线程ID，它常常用自增长的长整形1..n**实现–原生线程ID，例如:nid=0x251c**，之所以关键是因为原生线程ID可以让你获得诸如从操作系统的角度来看那个线程在你的JVM中使用了大部分的CPU时间等这样的相关信息.**–Java线程状态和详细信息，例如:waitingformonitorentry[0xfffffffea5afb000]java.lang.Thread.State:BLOCKED(onobjectmonitor)**可以快速的了解到线程状态极其当前阻塞的可能原因**–Java线程栈跟踪；这是目前为止你能从线程堆栈中找到的最重要的数据.这也是你花费最多分析时间的地方，因为Java栈跟踪向提供了你将会在稍后的练习环节了解到的导致诸多类型的问题的根本原因，所需要的90%的信息。–Java堆内存分解;从HotSpotVM1.6版本开始，在线程堆栈的末尾处可以看到HotSpot的内存使用情况，比如说Java的堆内存(YoungGen,OldGen)PermGen空间。这个信息对分析由于频繁GC而引起的问题时，是很有用的。你可以使用已知的线程数据或模式做一个快速的定位。?123456789HeapPSYoungGentotal466944K,used178734K[0xffffffff45c00000,0xffffffff70800000,0xffffffff70800000)edenspace233472K,76%used[0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)fromspace233472K,0%used[0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)tospace233472K,0%used[0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)PSOldGentotal1400832K,used1400831K[0xfffffffef0400000,0xffffffff45c00000,0xffffffff45c00000)objectspace1400832K,99%used[0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)PSPermGentotal262144K,used248475K[0xfffffffed0400000,0xfffffffee0400000,0xfffffffef0400000)objectspace262144K,94%used[0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)
jvm中虚拟机栈描述正确的是
一.虚拟机栈的特点：
栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。
JVM直接对Java栈的操作有两个，一个是每个 *** 的执行都伴随入栈，另一个是结束后出栈。
对于栈来说不存在垃圾回收问题
二.虚拟机栈可能出现的异常：
java 虚拟机规范允许Java栈的大小是动态的或者是固定不变的
如果采用固定大小的Java虚拟机栈，那每一个线程的Java虚拟机栈的容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机允许的更大容量，Java虚拟机将会抛出一个StackOverflowError异常。
如果Java虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存区创建对应的虚拟机栈，那Java虚拟机将会抛出一个OutOfMemoryError异常。
怎样使JAVA栈内存快速溢出
1.如果线程请求分配的栈容量超过java虚拟机栈允许的更大容量的时候，java虚拟机将抛出一个StackOverFlowError异常。 2.如果java虚拟机栈可以动态拓展，并且扩展的动作已经尝试过，但是目前无法申请到足够的内存去完成拓展，或者在建立新线程的时候没有足够的内存去创建对应的虚拟机栈，那java虚拟机将会抛出一个OutOfMemoryError异常。 刚看到题主在问题下的评论，xss分配的应该是每个线程的栈大小，线程数量和整个进程的大小是由操作系统来限制的。 对于单个线程，栈内存容量减小，或者变量表深度增大，就会造成StackOverFlow，这点我跟题主想的一样。 至于是堆内存溢出还是 *** 区内存溢出还是栈内存溢出，其实可以用一些工具比如 JConsole来监视。
怎么把Java运行时的虚拟机参数的栈大小调到256K以上
-Xss256K: 设置每个线程的运行时栈的大小为 256K。
相关参数：
-Xmx，设置JVM更大内存；比如 -Xmx512M: 设置JVM更大内存为512M；
-Xms，设置JVM最小内存；比如 -Xms512M: 设置JVM最小内存为512M；
-Xmn，设置JVM年轻代内存；比如 -Xmn1G：设置年轻代内存为 1 G。
如何检查和解决java虚拟机内存溢出的问题
一，jvm内存区域
1， 程序计数器
一块很小的内存空间，作用是当前线程所执行的字节码的行号指示器。
2， java栈
与程序计数器一样，java栈（虚拟机栈）也是线程私有的，其生命周期与线程相同。通常存放基本数据类型，对象引用（一个指向对象起始地址的引用指针或一个代表对象的句柄），reeturnAddress类型（指向一条字节码指令的地址）
栈区域有两种异常类型：如果线程请求的栈深度大于虚拟机所允许的深度，将抛StrackOverflowError异常；如果虚拟机栈可以动态扩展（大部分虚拟机都可动态扩展），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
3， 本地 *** 栈
与虚拟机栈作用很相似，区别是虚拟机栈为虚拟机执行java *** 服务，而本地 *** 栈则是为虚拟机用到的Native *** 服务。和虚拟机栈一样可能抛出StackOverflowError和OutOfMemoryError异常。
4， java堆
java
Heap是jvm所管理的内存中更大的区域。JavaHeap是被所有线程共享的一块内存区域，在虚拟机启动时创建。主要存放对象实例。JavaHeap
是垃圾收集器管理的主要区域，其可细分为新生代和老年代。如果在堆中没有内存完成实例分配，并且也无法再扩展时，会抛出OutOfMemoryError
异常。
5， *** 区
与javaHeap一样是各个线程共享的内存区域，用于存放已被虚拟机加载的类信息、常量、静态变量、及时编译器编译后的代码等数据。当 *** 区无法满足内
存分配的需求时，将抛出OutOfMemoryError异常。 *** 同时包含常听说的运行时常量池，用于存放编译期生成的各种字面量和符号引用。
6， 直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是java虚拟机规范中定义的内存区域，是jvm外部的内存区域，这部分区域也可能导致OutOfMemoryError异常。
二，jvm参数
-Xss（StackSpace）栈空间
-Xms ，-Xmx（heap memory
space）堆空间：Heap是大家最为熟悉的区域，他是jvm用来存储对象实例的区域，Heap在32位的系统中更大为2G，其大小通过-Xms和
-Xmx来控制，-Xms为jvm启动时申请的最小Heap内存，默认为物理内存的1/64，但小于1G，-Xmx为jvm可申请的更大的Heap内存，
默认为物理内存的1/4,一般也小于1G，默认当空余堆内存小于40%时，jvm会更大Heap的大小到-Xmx指定大小，可通过
-XX:MinHeapFreeRatio来指定这个比例，当空余堆内存大于70%时，JVM会将Heap的大小往-Xms指定的大小调整，可通过
-XX:MaxHeapFreeRatio来指定这个比例，但通常为了避免频繁调整HeapSize的大小，将-Xms和-Xmx的值设为相同。
-XX:PermSize -XX:MaxPermSize ： *** 区持久代大小： *** 区域也是全局共享的，在一定的条件下它也会被 GC ，当 *** 区域需要使用的内存超过其允许的大小时，会抛出 OutOfMemory 的错误信息。
三，常见内存溢出错误解决办法
1， OutOfMemoryError异常
除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能，
Java Heap 溢出
一般的异常信息：java.lang.OutOfMemoryError:Java heap spacess
java堆用于存储对象实例，我们只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，就会在对象数量达到更大堆容量限制后产生内存溢出异常。
出现这种异常，一般手段是先通过内存映像分析工具(如Eclipse Memory
Analyzer)对dump出来的堆转存快照进行分析，重点是确认内存中的对象是否是必要的，先分清是因为内存泄漏(Memory
Leak)还是内存溢出(Memory Overflow)。
如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。
如果不存在泄漏，那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。
2， 虚拟机栈和本地 *** 栈溢出
如果线程请求的栈深度大于虚拟机所允许的更大深度，将抛出StackOverflowError异常。
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常
这里需要注意当栈的大小越大可分配的线程数就越少。
3， 运行时常量池溢出
异常信息：java.lang.OutOfMemoryError:PermGen space
如果要向运行时常量池中添加内容，最简单的做法就是使用String.intern()这个Native *** 。该 *** 的作用是：如果池中已经包含一个等于
此String的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String
对象的引用。由于常量池分配在 *** 区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制 *** 区的大小，从而间接限制其中常量
池的容量。
4， *** 区溢出
*** 区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、 *** 描述等。
异常信息：java.lang.OutOfMemoryError:PermGen space
*** 区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。