firemail

标题: JVM JMM [打印本页]
作者: java    时间: 2019-1-23 16:04
标题: JVM JMM
本帖最后由 java 于 2019-2-13 17:42 编辑

https://www.cnblogs.com/yulinfeng/p/7153391.html

程序计数器（Program Counter Register）
　　这和计算机操作系统中的程序计数器类似，在计算机操作系统中程序计数器表示这个进程要执行的下个指令的地址，对于JVM中的程序计数器可以看做是当前线程所执行的字节码的行号指示器，每个线程都有一个程序计数器（这很好理解，每个线程都有在执行任务，如果线程切换后要能保证能恢复到正确的位置），重要的一点——程序计数器，这是JVM规范中唯一一个没有规定会导致OutOfMemory（内存泄露，下文简称OOM）的区域。换句话上图中的其余4个区域，都有可能导致OOM。
☆虚拟机栈（Java Virtual Machine Stacks）
　　这块内存区域就是我们常常说的“栈”，我们所熟知的是它用于存放变量,如： int i = 0;
虚拟机栈内存就会用4个字节来存储i变量。对于变量的内存空间是一开始就能确定的（对于引用型变量，它当然存储的就是一个地址引用，其大小也是固定），所以这块内存区域在编译器就能够确定下来，这块区域可能会抛出StackOverflowError或者OOM错误。设置JVM参数”-Xss228k”（栈大小为228k）。

对于单线程情况下，无论如何抛出的都是StackOverflowError。如果要抛出OOM异常，导致的原因是不断地在创建线程，直到将内存消耗殆尽。
　　JVM的内存由堆内存 + 方法区内存 + 剩余内存，也就是剩余内存=操作系统分配给JVM的内存 - 堆内存 - 方法区内存。-Xss设置的是每个线程的栈容量，也就是说可以创建的线程数量 = 剩余内存 / 栈内存。此时如果栈内存越大，可以创建的线程数量就少，就容易出现OOM；如果栈内存越小，可以创建的线程数量就多，就不容易出现OOM。
　　要避免这种情况最好就是减少堆内存+方法区内存，或者适当减少栈内存。对于栈内存的配置，一般采用默认值1M，或者采用64位操作系统以及64位的JVM。

本地方法栈（Native Method Stack）
　　本地方法栈和虚拟机栈类似，不同的是虚拟机栈服务的是Java方法，而本地方法栈服务的是Native方法。在HotSpot虚拟机实现中是把本地方法栈和虚拟机栈合二为一的，同理它也会抛出StackOverflowError和OOM异常。
☆Java堆（Java Heap）Java heap space
　　对于堆，Java程序员都知道对象实例以及数组内存都要在堆上分配。堆不再被线程所独有而是共享的一块区域，它的确是用来存放对象实例，也是垃圾回收GC的主要区域。实际上它还能细分为：新生代（Young Generation）、老年代（Old Generation）。对于新生代又分为Eden空间、From Survivor空间、To Survivor空间。至于为什么这么分，这涉及JVM的垃圾回收机制，在这里不做叙述。堆同样会抛出OOM异常，下面例子设置JVM参数” -Xms20M -Xmx20M“（前者表示初始堆大小20M，后者表示最大堆大小20M）。

☆方法区（Method Area）Permanent Space
　　对于JVM的方法区，可能听得最多的是另外一个说法——永久代（Permanent Generation），呼应堆的新生代和老年代。方法区和堆的划分是JVM规范的定义，而不同虚拟机有不同实现，对于Hotspot虚拟机来说，将方法区纳入GC管理范围，这样就不必单独管理方法区的内存，所以就有了”永久代“这么一说。方法区和操作系统进程的正文段（Text Segment）的作用非常类似，它存储的是已被虚拟机加载的类信息、常量（从JDK7开始已经移至堆内存中）、静态变量等数据。现设置JVM参数为”-XX:MaxPermSize=20M”（方法区最大内存为20M）。

String的intern()方法

API上的那几句关于这个方法，其实总结一句就是调用这个方法之后把字符串对象加入常量池中，常量池我们都知道他是存在于方法区的，他是方法区的一部分，而方法区是线程共享的，所以常量池也就是线程共享的，但是他并不是线程不安全的，他其实是线程安全的，他仅仅是让有相同值的引用指向同一个位置而已，如果引用值变化了，但是常量池中没有新的值，那么就会新开辟一个常量结果来交给新的引用，而并非像线程不同步那样，针对同一个对象，new出来的字符串和直接赋值给变量的字符串存放的位置是不一样的，前者是在堆里面，而后者在常量池里面，另外，在做字符串拼接操作，也就是字符串相"+"的时候，得出的结果是存在在常量池或者堆里面，这个是根据情况不同不一定的
实际上对于以上代码，在JDK6、JDK7、JDK8运行结果均不一样。原因就在于字符串常量池在JDK6的时候还是存放在方法区（永久代）所以它会抛出OutOfMemoryError: Permanent Space；而JDK7后则将字符串常量池移到了Java堆中，上面的代码不会抛出OOM，若将堆内存改为20M则会抛出OutOfMemoryError:Java heap space；至于JDK8则是纯粹取消了方法区这个概念，取而代之的是”元空间（Metaspace）“，所以在JDK8中虚拟机参数”-XX:MaxPermSize”也就没有了任何意义，取代它的是”-XX:MetaspaceSize“和”-XX:MaxMetaspaceSize”等。


  1）年轻代(Young Gen)：年轻代主要存放新创建的对象，内存大小相对会比较小，垃圾回收会比较频繁。年轻代分成1个Eden Space和2个Suvivor Space（命名为A和B）。当对象在堆创建时，将进入年轻代的Eden Space。垃圾回收器进行垃圾回收时，扫描Eden Space和A Suvivor Space，如果对象仍然存活，则复制到B Suvivor Space，如果B Suvivor Space已经满，则复制到Old Gen。同时，在扫描Suvivor Space时，如果对象已经经过了几次的扫描仍然存活，JVM认为其为一个持久化对象，则将其移到Old Gen。扫描完毕后，JVM将Eden Space和A Suvivor Space清空，然后交换A和B的角色（即下次垃圾回收时会扫描Eden Space和B Suvivor Space。这么做主要是为了减少内存碎片的产生。

我们可以看到：Young Gen垃圾回收时，采用将存活对象复制到到空的Suvivor Space的方式来确保尽量不存在内存碎片，采用空间换时间的方式来加速内存中不再被持有的对象尽快能够得到回收。

      2）年老代(Tenured Gen)：年老代主要存放JVM认为生命周期比较长的对象（经过几次的Young Gen的垃圾回收后仍然存在），内存大小相对会比较大，垃圾回收也相对没有那么频繁（譬如可能几个小时一次）。年老代主要采用压缩的方式来避免内存碎片（将存活对象移动到内存片的一边，也就是内存整理）。当然，有些垃圾回收器（譬如CMS垃圾回收器）出于效率的原因，可能会不进行压缩。

      3）持久代(Perm Gen)：持久代主要存放类定义、字节码和常量等很少会变更的信息。

JVM区域总体分两类，heap区和非heap区。heap区又分：Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区）。 非heap区又分：Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。


https://blog.csdn.net/jisuanjiguoba/article/details/80156781

命令行输入 jconsole 监控指定程序的JVM使用



jvm.png (56.89 KB, 下载次数: 544)

jvm.png




欢迎光临 firemail (http://firemail.wang:8088/) Powered by Discuz! X3