JVM入门

面试问题：

请谈谈你对JVM的理解?java8版有什么了解？

谈谈JVM中你对ClassLoader类加载器的认识？

什么是OOM？写代码使得分别出现StackOverflowError和OutOfMemoryError

package com.mikey.demo;

/**
 * @Program: TestJvm
 * @Author: 麦奇
 * @Email： 1625017540@qq.com
 * @Create: 2019-04-06 11:19
 * @Describe：
 **/
public class TestDemoSteakOverFlow {
    public static void main(String[] args){

        sayHello();

    }

    private static void sayHello() {
        sayHello();
    }
}
TestDemoSteakOverFlow
package com.mikey.demo;

import java.util.Random;

/**
 * @Program: TestJvm
 * @Author: 麦奇
 * @Email： 1625017540@qq.com
 * @Create: 2019-04-06 12:12
 * @Describe：
 **/
public class TestOutOfMemoryErrorDemo {
    public static void main(String[] args){

        String str="mikey";

        while (true){
            str+=str+new Random().nextInt(88888)+new Random().nextInt(999999999);
        }

    }
}
TestOutOfMemoryErrorDemo
2019-04-06 12:16:12
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode):

"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00007f8f5c1f3000 nid=0x776d runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread2" #8 daemon prio=9 os_prio=0 tid=0x00007f8f5c1ee000 nid=0x776c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #7 daemon prio=9 os_prio=0 tid=0x00007f8f5c1ec800 nid=0x776b waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #6 daemon prio=9 os_prio=0 tid=0x00007f8f5c1ea800 nid=0x776a waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Monitor Ctrl-Break" #5 daemon prio=5 os_prio=0 tid=0x00007f8f5c1e8800 nid=0x7769 runnable [0x00007f8f40f9d000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    at java.net.SocketInputStream.read(SocketInputStream.java:171)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
    at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
    - locked <0x00000006c99cbbd0> (a java.io.InputStreamReader)
    at java.io.InputStreamReader.read(InputStreamReader.java:184)
    at java.io.BufferedReader.fill(BufferedReader.java:161)
    at java.io.BufferedReader.readLine(BufferedReader.java:324)
    - locked <0x00000006c99cbbd0> (a java.io.InputStreamReader)
    at java.io.BufferedReader.readLine(BufferedReader.java:389)
    at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f8f5c181800 nid=0x7768 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f8f5c14f000 nid=0x7767 in Object.wait() [0x00007f8f41b6e000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006c99d9920> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
    - locked <0x00000006c99d9920> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f8f5c14c800 nid=0x7766 in Object.wait() [0x00007f8f41c6f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006c99d9b50> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:502)
    at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
    - locked <0x00000006c99d9b50> (a java.lang.ref.Reference$Lock)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007f8f5c00d800 nid=0x7756 runnable [0x00007f8f6329b000]
   java.lang.Thread.State: RUNNABLE
    at java.util.Arrays.copyOf(Arrays.java:3332)
    at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
    at java.lang.StringBuilder.append(StringBuilder.java:136)
    at com.mikey.demo.TestOutOfMemoryErrorDemo.main(TestOutOfMemoryErrorDemo.java:18)

"VM Thread" os_prio=0 tid=0x00007f8f5c142800 nid=0x7765 runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f8f5c023000 nid=0x775b runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f8f5c025000 nid=0x775c runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f8f5c026800 nid=0x775d runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f8f5c028800 nid=0x7761 runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007f8f5c1f6000 nid=0x776e waiting on condition 

JNI global references: 12

Heap
 PSYoungGen      total 139264K, used 121149K [0x000000076d180000, 0x000000077e180000, 0x00000007c0000000)
  eden space 129024K, 93% used [0x000000076d180000,0x00000007747cf630,0x0000000774f80000)
  from space 10240K, 0% used [0x0000000774f80000,0x0000000774f80000,0x0000000775980000)
  to   space 10240K, 0% used [0x000000077d780000,0x000000077d780000,0x000000077e180000)
 ParOldGen       total 2103808K, used 2050101K [0x00000006c7400000, 0x0000000747a80000, 0x000000076d180000)
  object space 2103808K, 97% used [0x00000006c7400000,0x000000074460d688,0x0000000747a80000)
 Metaspace       used 3023K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 330K, capacity 388K, committed 512K, reserved 1048576K

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3332)
    at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
    at java.lang.StringBuilder.append(StringBuilder.java:208)
    at com.mikey.demo.TestOutOfMemoryErrorDemo.main(TestOutOfMemoryErrorDemo.java:18)

Process finished with exit code 1
Error Message

JVM的常用参数调优你了解吗？

内存快照抓取和MAT分析hprof文件干过吗？

JVM体系结构概述

jvm位置：

JVM是运行在操作系统之上的，它与硬件没有直接的交互

JVM体系结构概览：

类装载器ClassLoader

负责加载class文件，class文件在文件开头有特定的文件标示，并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定

类装载器ClassLoader2

虚拟机自带的加载器
启动类加载器（Bootstrap）C++
扩展类加载器（Extension）Java
应用程序类加载器（App）Java
也叫系统类加载器，加载当前应用的classpath的所有类

用户自定义加载器  Java.lang.ClassLoader的子类，用户可以定制类的加载方式

 

类装载器ClassLoader3

Code案例

sun.misc.Launcher
它是一个java虚拟机的入口应用

某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

Execution Engine执行引擎负责解释命令，提交操作系统执行。

 Native Interface本地接口

    Java语言本身不能对操作系统底层进行访问和操作，但是可以通过JNI接口调用其他语言来实现对底层的访问。        
本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合 C/C++程序，Java诞生的时候是C/C++横行的时候，
要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为Native的代码，
它的具体做法是Native Method Stack中登记Native方法，在Execution Engine 执行时加载Native libraries。
    目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，
在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，
也可以使用WebService等等，不多做介绍。

Native Method Stack

它的具体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载本地方法库。

PC寄存器

    每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。

栈

    栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。基本类型的变量、实例方法、引用类型变量都是在函数的栈内存中分配。
Exception in thread "main" java.lang.StackOverflowError

方法区

1：方法区是线程共享的，通常用来保存装载的类的元结构信息。
比如：运行时常量池+静态变量+常量+字段+方法字节码+在类/实例/接口初始化用到的特殊方法等。

2：通常和永久区关联在一起(Java7之前)，但具体的跟JVM的实现和版本有关。

堆体系结构概述

Heap堆(Java7之前)
    一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行。
堆内存逻辑上分为三部分：新生+养老+永久

新生区
    新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存0区.若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC（FullGC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：
（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。
新生区

堆参数调优入门

 Java7

 Java8

 JDK 1.8之后将最初的永久代取消了，由元空间取代。

（堆内存调优简介01）

 

public static void main(String[] args){
long maxMemory = Runtime.getRuntime().maxMemory() ;//返回 Java 虚拟机试图使用的最大内存量。
long totalMemory = Runtime.getRuntime().totalMemory() ;//返回 Java 虚拟机中的内存总量。
System.out.println("MAX_MEMORY = " + maxMemory + "（字节）、" + (maxMemory / (double)1024 / 1024) + "MB");
System.out.println("TOTAL_MEMORY = " + totalMemory + "（字节）、" + (totalMemory / (double)1024 / 1024) + "MB");
}
View Code

 （堆内存调优简介02）

发现默认的情况下分配的内存是总内存的“1 / 4”、而初始化的内存为“1 / 64”

VM参数：    -Xms1024m -Xmx1024m -XX:+PrintGCDetails

（堆内存调优简介03）此图为java7，演示为8

 

（堆内存调优简介04）

String str = "www.atguigu.com" ;
while(true) 
{
str += str + new Random().nextInt(88888888) + new Random().nextInt(999999999) ;
}
View Code
VM参数：-Xms8m -Xmx8m -XX:+PrintGCDetails

 

 

 

-XX:+HeapDumpOnOutOfMemoryError
OOM时导出堆到hprof文件。
-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

强引用，弱引用,软引用，虚引用

 

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/biaogejiushibiao/p/10660620.html