jvm

JVM性能调优监控工具jps、jstack、jstat、jmap、jinfo使用详解 https://www.cnblogs.com/baihuitestsoftware/articles/6382733.html jps 查看所有的jvm进程，包括进程ID，进程启动的路径等等。 我自己也用PS，即：ps -ef | grep java jstack 观察jvm中当前所有线程的运行情况和线程当前状态。 系统崩溃了？如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。 系统hung住了？jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。 jstat jstat利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对进程的classloader，compiler，gc情况； 特别的，一个极强的监视内存的工具，可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量，以及加载类的数量。 jmap 监视进程运行中的jvm物理内存的占用情况，该进程内存内

jstat 用于查看服务器上某个服务的GC情况。 一般使用方式 jstat –gcpid 或 jstat –utilpid 时间间隔—每个一定时间（指定的时间间隔）输出一次进程pid的内存情况及gc情况。 类加载统计(-class) Loaded Bytes Unloaded Bytes Time 加载class的数量 所占用空间大小 未加载数量 未加载占用空间 时间 [lillcol@node1 lillcol]# jstat -class 22363 Loaded Bytes Unloaded Bytes Time 19410 39919.5 112 155.0 10.18 编译统计(-compiler) Compiled Failed Invalid Time FailedType FailedMethod 编译数量 失败数量 不可用数量 时间 失败类型 失败的方法 [lillcol@node1 lillcol]# jstat -compiler 22363 Compiled Failed Invalid Time FailedType FailedMethod 25021 2 0 71.64 1 org/apache/spark/ContextCleaner$$anonfun$org$apache$spark$ContextCleaner$$keepCleaning$1

jps: 主要用来输出JVM中运行的进程状态信息 option: -q 忽略输出的类名、Jar名以及传递给main方法的参数，只输出pid。 -m 输出传递给main方法的参数，如果是内嵌的JVM则输出为null。 -l 输出应用程序主类的完整包名，或者是应用程序JAR文件的完整路径。 -v 输出传给JVM的参数。 -V 输出通过标记的文件传递给JVM的参数（.hotspotrc文件，或者是通过参数-XX:Flags=<filename>指定的文件） jstat: jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]] -gcutil 统计heap的gc情况 -t 在第一列输出时间戳。该时间戳从jvm启动开始 -h3 每隔N行输出一次列表头 $PID 进程号 interval 输出间隔时间，单位毫秒 count 输出次数 Demo: jstat -gcutil -t -h5 7919 1000 50 jinfo 观察运行中的java程序的运行环境参数：参数包括Java System属性和JVM命令行参数 Demo: jinfo 14352 jinfo -sysprops 14352 jinfo -flags 14352 jinfo -flag MaxPermSize 14352 jmap 用来查看堆内存使用状况

1.概述 Jcmd是一个诊断Jvm的命令集工具, 集成了包括Jps, Jstack以及采集JFR信息等功能. 它必须运行在被诊断Jvm进程的同一台机器上. １）查询JVM进程及PID /dapeng-container/bin # jcmd -l 252 sun.tools.jcmd.JCmd -l 13 com.github.dapeng.bootstrap.Bootstrap ２）查询指定进程及 /dapeng-container/bin # jcmd 13 VM.flags 13: -XX:CICompilerCount=3 -XX:+HeapDumpOnOutOfMemoryError -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456 -XX:MaxNewSize=134217728 -XX:MinHeapDeltaBytes=524288 -XX:NewRatio=1 -XX:NewSize=134217728 -XX:OldSize=134217728 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=30 -XX:ThreadStackSize=256 -XX:

类加载机制 类加载器负责加载所有的类，系统为所有被载入内存中的类生成一个 java.lang.Class 实例。一旦一个类被载入 JVM 中，同个类就不会被再次载入了。现在的问题是，怎么样才算“同一个类”？ 正如一个对象有一个唯一的标识一样，一个载入 JVM 中的类也有一个唯一的标识。在 Java 中，一个类用其全限定类名（包括包名和类名）作为标识：但在 JVM 中，一个类用其全限定类名和其类加载器作为唯一标识。例如，如果在 pg 的包中有一个名为 Person 的类，被类加载器 ClassLoader 的实例 k1 负责加载，则该 Person 类对应的 Class 对象在 JVM 中表示为（Person、pg、k1）。这意味着两个类加载器加载的同名类：（Person、pg、k1）和（Person、pg、k12）是不同的，它们所加载的类也是完全不同、互不兼容的。 当 JVM 启动时，会形成由三个类加载器组成的初始类加载器层次结构。 Bootstrap ClassLoader：根类加载器。 Extension ClassLoader：扩展类加载器。 System ClassLoader：系统类加载器。 Bootstrap ClassLoader 被称为引导（也称为原始或根）类加载器，它负责加载 Java 的核心类。在Sun 的 JVM 中，当执行 java.exe 命令时，使用

刚从京东面试回来，我才知道这些JVM知识有多重要 面试题 关于JVM的知识之前也写过相关的文章整理，但是从京东面试后，才发现这些JVM的知识点尤为重要，所以特意整理出来以供大家参考。 1.什么是类的加载？ 2.哪些情况会触发类的加载？ 3.讲一下JVM加载一个类的过程 4.什么时候会为变量分配内存？ 5.JVM的类加载机制是什么？ 6.双亲委派机制可以打破吗？为什么 答案放在文章的最后，来不及看原理也可以直接跳到最后直接看答案。 深入原理 类的生命周期 类的生命周期相信大家已经耳熟能详，就像下面这样： 不过这东西总是背了就忘，忘了又背，就像马什么梅一样，对吧？ 其实理解之后，基本上就不会再忘了。 加载 加载主要做三件事： 1.找到类文件（通过类的全限定名来获取定义此类的二进制字节流） 2.放入方法区（将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构） 3.开个入口（生成一个代表此类的java.lang.Class对象，作为访问方法区这些数据结构的入口） 总的来讲，这一步就是通过类加载器把类读入内存。需要注意的是，第三步虽然生成了对象，但并不在堆里，而是在方法区里。 连接 连接分为三步，一般面试都比较喜欢问准备这一步。 校验 顾名思义，检查Class文件的字节流中包含的信息是否符合当前虚拟机的要求。 准备 这一步中将为静态变量和静态常量分配内存，并赋值。 需要注意的是

3 月，跳不动了？>>> 在Java程序中，多线程几乎已经无处不在。与单线程相比，多线程程序的设计和实现略微困难，但通过多线程，我们却可以获得多核CPU带来的性能飞跃，从这个角度说，多线程是一种值得尝试的技术。那么如何写出高效的多线程程序呢？ 1、有关多线程的误区：线程越多，性能越好 不少初学者可能认为，线程数量越多，那么性能应该越好。因为程序给我们的直观感受总是这样。一个两个线程可能跑的很难，线程一多可能就快了。但事实并非如此。因为一个物理CPU一次只能执行一个线程，多个线程则意味着必须进行线程的上下文切换，而这个代价是很高的。因此，线程数量必须适量，最好的情况应该是N个CPU使用N个线程，并且让每个CPU的占有率都达到100%，这种情况下，系统的吞吐量才发挥到极致。但现实中，不太可能让单线程独占CPU达到100%，一个普遍的愿意是因为IO操作，无论是磁盘IO还是网络IO都是很慢的。线程在执行中会等待，因此效率就下来了。这也就是为什么在一个物理核上执行多个线程会感觉效率高了，对于程序调度来说，一个线程等待时，也正是其它线程执行的大好机会，因此，CPU资源得到了充分的利用。 2、尽可能不要挂起线程 多线程程序免不了要同步，最直接的方法就是使用锁。每次只允许一个线程进入临界区，让其它相关线程等待。等待有2种，一种是直接使用操作系统指令挂起线程，另外一种是自旋等待。在操作系统直接挂起

jvm 语法糖主要包括： 1. 泛型 相同擦除类型参数，返回值不同也可以编译成功, 对比方法重载矛盾。 原因：class文件格式中，只要描述符不是完全一致的两个方法就可以共存。 擦除：擦除方法code属性中字节码擦除，元数据还保留在泛型中，可以通过反射获取参数化类型。 3. 装箱拆箱：Integer.valueOf()，Integer.intValue() 4. for循环，把遍历循环代码还原成了迭代器实现，因此需要被遍历的类实现Iterable接口。 5. 变长参数：调用的时候变成了数组类型参数。 6. 条件编译：使用条件为常量的if语句，根据布尔常量值的真假，编译器会把分支中不成立的代码块消除（接触语法糖阶段） java语言编译方式：将所有编译单元语法书顶级节点输入到待处理列表再进行编译，各个文件之间能相互提供符号信息。 7. 内部类 Java的内部类也是一个语法糖，它仅仅是一个编译时的概念，outer.java里面定义了一个内部类inner，一旦编译成功，就会生成两个完全不同的.class文件了，分别是outer.class和outer$inner.class。所以内部类的名字完全可以和它的外部类名字相同。 内部类分为四种：成员内部类、局部内部类、匿名内部类、静态内部类。 8. 枚举类 在JVM字节码文件结构中，并没有“枚举”这个类型。Java的枚举类型

前言 什么是JVM的GC，GC(Garbage Collection)也就是垃圾回收是JVM在内存空间不足等必要条件下自动清除应用程序中的垃圾对象，回收垃圾对象占用的内存空间。 JVM的GC机制使得开发者从繁琐的内存管理中释放出来，只需要专注于业务开发。但即便如此，这并不意味着我们可以不用去理解GC的原理，如果不了解GC原理的话，那么当我们在实际工作中遇到了内存泄漏、频繁GC导致应用性能低下的问题时往往会变得束手无措，为了能够快速排查问题、解决性能瓶颈，我们需要对GC原理有所了解。 想要了解GC原理，我们需要先了解JVM内存管理机制，了解JVM中内存的划分，这样才能更好的了解垃圾回收是回收的是哪些区域的垃圾对象，什么时候回收以及怎么回收。 JVM的内存管理 根据JVM规范( 这里及下文的规范均为Java8的规范 )，JVM把内存划分成了几个不同的区域： 程序计数器(线程独享) 方法区(线程共享) 堆区(线程共享) 虚拟机栈(线程独享) 本地方法栈(线程独享) 其中，方法区和堆区为所有线程共用的数据区域，程序计数器、虚拟机栈、本地方法栈为各个线程独有的区域，不同的区域作用不尽相同。 对于线程独享的区域，区域创建于线程创建之时，销毁于线程退出之时。对于线程共享的区域，区域创建于虚拟机启动之时，销毁于虚拟机退出之时。 # 程序计数器 程序计数器为 线程独享 区域

在EHCache中，可以设置maxBytesLocalHeap、maxBytesLocalOffHeap、maxBytesLocalDisk值，以控制Cache占用的内存、磁盘的大小（注：这里Off Heap是指Element中的值已被序列化，但是还没写入磁盘的状态，貌似只有企业版的EHCache支持这种配置；而这里maxBytesLocalDisk是指在最大在磁盘中的数据大小，而不是磁盘文件大小，因为磁盘文中有一些数据是空闲区），因而EHCache需要有一种机制计算一个类在内存、磁盘中占用的字节数，其中在磁盘中占用的字节大小计算比较容易，只需要知道序列化后字节数组的大小，并且加上一些统计信息，如过期时间、磁盘位置、命中次数等信息即可，而要计算一个对象实例在内存中占用的大小则要复杂一些。 计算一个实例内存占用大小思路 在Java中，除了基本类型，其他所有通过字段包含其他实例的关系都是引用关系，因而我们不能直接计算该实例占用的内存大小，而是要递归的计算其所有字段占用的内存大小的和。在Java中，我们可以将所有这些通过字段引用简单的看成一种树状结构，这样就可以遍历这棵树，计算每个节点占用的内存大小，所有这些节点占用的内存大小的总和就当前实例占用的内存大小，遍历的算法有：先序遍历、中序遍历、后序遍历、层级遍历等。但是在实际情况中很容易出现环状引用（最简单的是两个实例之间的直接引用