JVM 面试 4 连炮，你能顶住么？
击上方的终端研发部，右上角选择“设为星标”
每日早9点半，技术文章准时送上html
公众号后台回复“学习”，获取做者独家秘制精品资料java
做者：melonstreet，linux
连接：www.cnblogs.com/QG-whz/p/9636366.htmlandroid
正文
下面总结了 JVM 的 4 个问题，看你能顶住么？
程序员
一、JVM的内存区域是怎么划分的？多线程
JVM的内存划分中，有部分区域是线程私有的，有部分是属于整个JVM进程；有些区域会抛出OOM异常，有些则不会，了解JVM的内存区域划分以及特征，是定位线上内存问题的基础。那么JVM内存区域是怎么划分的呢？
首先是程序计数器（Program Counter Register)，在JVM规范中，每一个线程都有本身的程序计数器。这是一块比较小的内存空间，存储当前线程正在执行的Java方法的JVM指令地址，即字节码的行号。若是正在执行Native方法，则这个计数器为空。该内存区域是惟一一个在Java虚拟机规范中没有规定任何OOM状况的内存区域。
第二，Java虚拟机栈(Java Virtal Machine Stack)，一样也是属于线程私有区域，每一个线程在建立的时候都会建立一个虚拟机栈，生命周期与线程一致，线程退出时，线程的虚拟机栈也回收。虚拟机栈内部保持一个个的栈帧，每次方法调用都会进行压栈，JVM对栈帧的操做只有出栈和压栈两种，方法调用结束时会进行出栈操做。
该区域存储着局部变量表，编译时期可知的各类基本类型数据、对象引用、方法出口等信息。
第三，本地方法栈（Native Method Stack）与虚拟机栈相似，本地方法栈是在调用本地方法时使用的栈，每一个线程都有一个本地方法栈。
第四，堆（Heap）,几乎全部建立的Java对象实例，都是被直接分配到堆上的。堆被全部的线程所共享，在堆上的区域，会被垃圾回收器作进一步划分，例如新生代、老年代的划分。Java虚拟机在启动的时候，可使用“Xmx”之类的参数指定堆区域的大小。
第五，方法区（Method Area)。方法区与堆同样，也是全部的线程所共享，存储被虚拟机加载的元（Meta）数据，包括类信息、常量、静态变量、即时编译器编译后的代码等数据。这里须要注意的是运行时常量池也在方法区中。
根据Java虚拟机规范的规定，当方法区没法知足内存分配需求时，将抛出OutOfMemoryError异常。因为早期HotSpot JVM的实现，将CG分代收集拓展到了方法区，所以不少人会将方法区称为永久代。Oracle JDK8中已永久代移除永久代，同时增长了元数据区（Metaspace）。
第六，运行时常量池（Run-Time Constant Pool)，这是方法区的一部分，受到方法区内存的限制，当常量池没法再申请到内存时，会抛出OutOfMemoryError异常。
在Class文件中，除了有类的版本、方法、字段、接口等描述信息外，还有一项信息是常量池。每一个Class文件的头四个字节称为Magic Number，它的做用是肯定这是不是一个能够被虚拟机接受的文件；接着的四个字节存储的是Class文件的版本号。紧挨着版本号以后的，就是常量池入口了。常量池主要存放两大类常量：
字面量（Literal），如文本字符串、final常量值
符号引用，存放了与编译相关的一些常量，由于Java不像C++那样有链接的过程，所以字段方法这些符号引用在运行期就须要进行转换，以便获得真正的内存入口地址。
class文件中的常量池，也称为静态常量池，JVM虚拟机完成类装载操做后，会把静态常量池加载到内存中，存放在运行时常量池。
第七，直接内存（Direct Memory），直接内存并不属于Java规范规定的属于Java虚拟机运行时数据区的一部分。Java的NIO可使用Native方法直接在java堆外分配内存，使用DirectByteBuffer对象做为这个堆外内存的引用。
下面这张图，反映了运行中的Java进程内存占用状况：
二、OOM可能发生在哪些区域上？
根据javadoc的描述，OOM是指JVM的内存不够用了，同时垃圾收集器也没法提供更多的内存。从描述中能够看出，在JVM抛出OutOfMemoryError以前，垃圾收集器通常会出马先尝试回收内存。
从上面分析的Java数据区来看，除了程序计数器不会发生OOM外，哪些区域会发生OOM的状况呢？
第一，堆内存。堆内存不足是最多见的发送OOM的缘由之一，若是在堆中没有内存完成对象实例的分配，而且堆没法再扩展时，将抛出OutOfMemoryError异常。当前主流的JVM能够经过-Xmx和-Xms来控制堆内存的大小，发生堆上OOM的多是存在内存泄露，也多是堆大小分配不合理。
第二，Java虚拟机栈和本地方法栈，这两个区域的区别不过是虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为虚拟机使用到的Native方法服务，在内存分配异常上是相同的。
在JVM规范中，对Java虚拟机栈规定了两种异常：1.若是线程请求的栈大于所分配的栈大小，则抛出StackOverFlowError错误，好比进行了一个不会中止的递归调用；2. 若是虚拟机栈是能够动态拓展的，拓展时没法申请到足够的内存，则抛出OutOfMemoryError错误。
第三，直接内存。直接内存虽然不是虚拟机运行时数据区的一部分，但既然是内存，就会受到物理内存的限制。在JDK1.4中引入的NIO使用Native函数库在堆外内存上直接分配内存，但直接内存不足时，也会致使OOM。
第四，方法区。随着Metaspace元数据区的引入，方法区的OOM错误信息也变成了“java.lang.OutOfMemoryError:Metaspace”。对于旧版本的Oracle JDK，因为永久代的大小有限，而JVM对永久代的垃圾回收并不积极，若是往永久代不断写入数据，例如String.Intern()的调用，在永久代占用太多空间致使内存不足，也会出现OOM的问题，对应的错误信为“java.lang.OutOfMemoryError:PermGen space”
三、堆内存结构是怎么样的？
能够借助一些工具来了解JVM的内存内容，具体到特定的内存区域，应该用什么工具去定位呢？
图形化工具。图形化工具的优势是直观，链接到Java进程后，能够显示堆内存、堆外内存的使用状况，相似的工具备JConsole,VisualVm等。
命令行工具。这类工具能够在运行时进行查询，包括jstat，jmap等，能够对堆内存、方法区等进行查看。定位线上问题时也多会使用这些工具。jmap也能够生成堆转储文件（Heap Dump）文件，若是是在linux上，能够将堆转储文件拉到本地来，使用Eclipse MAT进行分析，也可使用jhap进行分析。
关于内存的监控与诊断，在后面会进行深刻了解。如今来看下一个问题：堆内的结构是怎么的呢？深刻浅出 Java 中 JVM 内存管理，这篇推荐看下。
站在垃圾收集器的角度来看，能够把内存分为新生代与老年代。内存的分配规则取决于当前使用的是哪一种垃圾收集器的组合，以及内存相关的参数配置。往大的方向说，对象优先分配在新生代的Eden区域，而大对象直接进入老年代。
第一, 新生代的Eden区域，对象优先分配在该区域，同时JVM能够为每一个线程分配一个私有的缓存区域，称为TLAB（Thread Local Allocation Buffer），避免多线程同时分配内存时须要使用加锁等机制而影响分配速度。TLAB在堆上分配，位于Eden中。TLAB的结构以下：
// ThreadLocalAllocBuffer: a descriptor for thread-local storage used by
// the threads for allocation.
// It is thread-private at any time, but maybe multiplexed over
// time across multiple threads. The park()/unpark() pair is
// used to make it avaiable for such multiplexing.
class ThreadLocalAllocBuffer: public CHeapObj<mtThread> {
friend class VMStructs;
private:
HeapWord* _start; // address of TLAB
HeapWord* _top; // address after last allocation
HeapWord* _pf_top; // allocation prefetch watermark
HeapWord* _end; // allocation end (excluding alignment_reserve)
size_t _desired_size; // desired size (including alignment_reserve)
size_t _refill_waste_limit; // hold onto tlab if free() is larger than this
从本质上来讲，TLAB的管理是依靠三个指针：start、end、top。start与end标记了Eden中被该TLAB管理的区域，该区域不会被其余线程分配内存所使用，top是分配指针，开始时指向start的位置，随着内存分配的进行，慢慢向end靠近，当撞上end时触发TLAB refill。
所以内存中Eden的结构大致为：
第二、新生代的Survivor区域。当Eden区域内存不足时会触发Minor GC，也称为新生代GC，在Minor GC存活下来的对象，会被复制到Survivor区域中。我认为Survivor区的做用在于避免过早触发Full GC。若是没有Survivor，Eden区每进行一次Minor GC都把对象直接送到老年代，老年代很快便会内存不足引起Full GC。
新生代中有两个Survivor区，我认为两个Survivor的做用在于提升性能，避免内存碎片的出现。在任什么时候候，总有一个Survivor是empty的，在发生Minor GC时，会将Eden及另外一个的Survivor的存活对象拷贝到该empty Survivor中，从而避免内存碎片的产生。新生代的内存结构大致为：
第三、老年代。老年代放置长生命周期的对象，一般是从Survivor区域拷贝过来的对象，不过当对象过大的时候，没法在新生代中用连续内存的存放，那么这个大对象就会被直接分配在老年代上。通常来讲，普通的对象都是分配在TLAB上，较大的对象，直接分配在Eden区上的其余内存区域，而过大的对象，直接分配在老年代上。
第四、永久代。如前面所说，在早起的Hotspot JVM中有老年代的概念，老年代用于存储Java类的元数据、常量池、Intern字符串等。在JDK8以后，就将老年代移除，而引入元数据区的概念。
第五、Vritual空间。前面说过，可使用Xms与Xmx来指定堆的最小与最大空间。若是Xms小于Xmx，堆的大小不会直接扩展到上限，而是留着一部分等待内存需求不断增加时，再分配给新生代。Vritual空间即是这部分保留的内存区域。
关注微信公众号：Java技术栈，在后台回复：JVM，能够获取我整理的 N 篇最新JVM 教程，都是干货。
那么综上所述，能够画出Java堆内的内存结构大致为：
经过一些参数，能够来指定上述的堆内存区域的大小：
-Xmx value 指定最大的堆大小
-Xms value 指定初始的最小堆大小
-XX:NewSize = value 指定新生代的大小
-XX：NewRatio = value 老年代与新生代的大小比例。默认状况下，这个比例是2，也就是说老年代是新生代的2倍大。老年代过大的时候，Full GC的时间会很长；老年代太小，则很容易触发Full GC，Full GC频率太高，这就是这个参数会形成的影响。
-XX：SurvivorRation = value . 设置Eden与Srivivor的大小比例，若是该值为8，表明一个Survivor是Eden的1/8，是整个新生代的1/10。
四、经常使用的性能监控与问题定位工具备哪些？
在系统的性能分析中，CPU、内存与IO是主要的关注项。不少时候服务出现问题，在这三者上会体现出现，好比CPU飙升，内存不足发生OOM等，这时候须要使用对应的工具，来对性能进行监控，对问题进行定位。
对于CPU的监控，首先可使用top命令来进行查看，下面是使用top查看负载的一个截图：
load average 表明1分钟、5分钟、15分钟的系统平均负载，从这三个数字，能够判断系统负荷是大仍是小。当CPU彻底空闲的时候，平均负荷为0；当CPU工做量饱和的时候，平均负荷为1。
所以 load average 这三个数值越低，表明系统负荷越小，那么何时能看出系统负荷比较重呢？这篇文章（Understanding Linux CPU Load – when should you be worried）里解释得很是通俗。若是电脑里只有一个CPU，把CPU当作一条单行桥，桥上只有一个车道，全部的车都必须从这个桥上经过。那么
系统负荷为0，表明桥上一辆车也没有
系统负荷0.5，意味着桥上一半路段上有车
系统负荷1，意味着桥上道路已经被车占满
系统负荷1.7，表明着在桥上车子已经满了（100%），同时还有70%的车子在等待从桥上经过：
从top命令的截图中能够看到这三个值机器的load average很是低。若是这三个值很是高，好比超过了50%或60%，就应当引发注意。从时间维度上来讲，若是发现CPU负荷慢慢升高，也须要警戒。
其余的内存、CPU等性能监控工具的使用，以一张脑图来展现：
具体的使用方式能够参考从一次线上故障思考Java问题定位思路。
参考
https://www.cnblogs.com/dreamroute/p/5946272.html
https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-2.html#jvms-2.5
https://www.cnblogs.com/Kidezyq/p/8040338.html
https://www.cnblogs.com/baihuitestsoftware/articles/6405580.html
https://www.jianshu.com/p/cd85098cca39
http://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html
阅读更多
没撑过2020，我从外包公司离职了
程序员接私活必备10 个开源项目！
相信本身，没有作不到的，只有想不到的
在这里得到的不只仅是技术！
喜欢就给个“在看”