jvm

• Read 最近学习《深入理解Java虚拟机》，书中使用的是JDK1.7，垃圾收集器使用CMS；而笔者环境为JDK10，垃圾收集默认使用G1。G1与CMS之间的差异挺大，日志格式也截然不同，而目前主流的是G1收集器，故重点学习G1。笔者最近入门学习JVM，以下理解有错的烦请指出，不甚感激～ 测试一 测试代码 1234567891011121314151617181920212223 package main.GCtest;public class { private static final int _1MB = 1024 * 1024; * VM参数： -Xms20M -Xmx20M -Xmn10M -Xlog:gc* * -Xmn10M 指分配10M给新生代，Java堆剩余的分配给老年代 * -Xlog:gc* 发生垃圾收集时打印内存回收日志，并在进程退出时输出当前的内存各区域分配情况 */ public static void () { byte[] allocation1, allocation2, allocation3, allocation4,allocation5,allocation6; allocation1 = new byte[2 * _1MB]; allocation2 = new byte[2 * _1MB]; allocation3 = new

JVM内存的系统级的 调优主要的目的 是减少Minor GC的频率和Full GC的次数，过多的Minor GC和Full GC是会占用很多的系统资源，影响系统的吞吐量 概念 - -Xss：规定了每个线程虚拟机栈（堆栈）的大小 JDK5.0以后每个线程堆栈大小为1M。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。 - -Xms：堆的初始值 - -Xmx：堆可以达到的最大值 注 ：Xms一般设置为Xmx同等大小，因为系统扩容时容易引起内存抖动，影响程序运行时的稳定性；同时以避免每次垃圾回收完成后JVM重新分配内存。 补充学习 Java内存模型及性能优化 来源： CSDN 作者： 大鱼七号船船长 链接： https://blog.csdn.net/lehek/article/details/104448386

JVM即Java虚拟机,主要用来编译,执行Java代码,并在执行过程中对内存进行管理. Java代码的执行流程 Java代码首先要通过javac前期编译器从.java文件编译为.class字节码文件(注解处理),然后将.class文件交由虚拟机的类加载器ClassLoader进行装载(采用 双亲委派机制 进行装载),将.class文件装入java虚拟机后,Hotspot虚拟机根据配置的模式( 混合模式,解释模式,编译模式 )来决定使用解释器直接 解释执行 还是使用 JIT即时编译器 进行 编译执行 ,亦或者是两者混用的混合模式进行执行.默认采用混合模式执行. Hotspot虚拟机内置了两个即时编译器,称为 client编译器 和 server编译器 (C1,C2编译器),前者进行一些稳定可靠的优化,后者还会进行一些激进不可靠的优化策略.后者编译出的机器码相对前者质量要高,而前者进行编译的速度要比后者快. 可靠的编译优化: 热点代码替换 , 栈上替换 .原理:基于采样的热点探测,方法调用计数器和回边计数器. 方法内联 基于逃逸分析的编译优化:栈上分配, 标量替换 , 同步消除 . java运行时数据区 程序运行后要对内存进行管理,Java虚拟机的运行时数据区分为 堆 , 虚拟机栈 , 本地方法栈 , 程序计数器 , 元空间 堆 中存放着对象(大小不固定), 虚拟机栈

类加载器的作用不仅仅是实现类的加载，它还与类的的“相等”判定有关，关系着Java“相等”判定方法的返回结果，只有在满足如下三个 类“相等”判定条件 ，才能判定两个类相等。 1、两个类来自同一个Class文件 2、两个类是由同一个虚拟机加载 3、两个类是由同一个类加载器加载 JVM类加载器 启动类加载器（bootstrap classLoader）：启动类加载器，负责加载java的核心类库，加载如（%JAVA_HOME%/lib）下的rt.jar（包含System，String等核心类）这样的核心类库。根类加载器不是classLoader的子类，它是JVM自身内部由C/C++实现的，并不是Java实现的。 扩展类加载器（Extension classLoader）：扩展类加载器，负责加载扩展目录（%JAVA_HOME%/jre/lib/ext）下的jar包，用户可把自己开发的类的jar放入ext目录下，即可扩展除核心类以为的新功能。 系统类加载器（Application classLoader）：系统类加载器或称为应用程序类加载器，是加载CLASSPATH环境变量所指定的jar包与类路径。一般来说，用户自定义的类就是由APP ClassLoader加载的。 类加载器的双亲委派模型机制 当一个类收到了类加载的请求，他首先不会自己尝试加载这个类，而是将这个请求委派给父类加载器来完成

一、类加载过程 类加载： 类加载器将.class字节码文件加载进Java虚拟机的内存中 。 加载 ：在硬盘上查找并通过IO读入字节码文件 连接 ：执行校验、准备、解析（可选）步骤 校验 ：校验字节码文件的正确性 准备 ：给类的静态变量分配内存，并赋予默认值 解析 ：类加载器载入类所引用的其他所有类 初始化 ：对类的静态变量初始化为指定的值，执行静态代码块 二、类加载器种类 引导类加载器 ：负责加载JRE的核心类库，如JRE目标下的rt.jar、charsets.jar等 扩展类加载器 ：负责加载JRE扩展目录ext中的jar类包 系统类加载器 ：负责加载ClassPath路径下的类包 自定义类加载器 ：负责加载用户自定义路径下的类包 例子：定义一个TestJDKClassLoader类。 运行结果： 分析：第一个为null（其实就是引导类加载器，引导类加载器是用C和C++写的，不在JDK中，根本不知道它的名字，类似于native方法），第二个为扩展类加载器，第三、四个为系统类加载器。 三、类加载机制 全盘负责委托机制：当一个ClassLoader加载一个类时，除非显示的使用另一个ClassLoader，否则该类所依赖和引用的类也由这个ClassLoader载入 双亲委派机制 ：指先委托父类加载器寻找目标类，在找不到的情况下再从自己的路径中查找并载入目标类 双亲委派模式的优势：

背景 组内有好几个线上服务，除了业务逻辑不一样，请求处理过程基本上都是一致的。这些服务的执行逻辑都非常简单，但是有几个问题: 单机QPS很低，需要很多台机器 99分位耗时比理论上的长很多 在服务的负载达到上限时，服务器的负载却非常低 上面的这些问题在财大气粗的公司面前都不是问题啊，性能不够加机器！ 性能不够加机器！ 上游再一次过来反映超时问题时，为了壮年程序员的尊严，这次刚好有时间决定不再单纯的加机器，要把这个程序优化一下，用一次屠龙技。 技术栈： 语言：java 通信方式：thrift，server模式为THsHaServer redis客户端：jedis 模型：xgboost 执行环境：docker，8核 8G 缓存集群：通信协议为redis，但实现方式和redis不一样 优化后结果 优化过程 想要提升程序的性能，首先需要找到程序的瓶颈所在，然后有针对的去进行优化。 流程分析 优化前流程图 这个流程图省略了业务处理逻辑，只展示了各个线程之间的交互关系。构造redis请求的那部分逻辑，其实使用了两个forkjoin线程池，但它们两个的逻辑非常类似，为了简化把它们合并到一个流程中了。流程图中有两个深红色的步骤，很明显的看出两个明显能影响性能的地方。 结合服务的执行环境，可以总结出以下问题： 线程数过多 由于操作系统对线程的抢占式调度，线程频繁的上下文切换会带来几个问题：

带着问题，尤其是面试问题的学习才是最高效的。加油，奥利给！ 点赞+收藏 就学会系列，文章收录在 GitHub JavaEgg ，N线互联网开发必备技能兵器谱 直击面试 看你简历写得熟悉JVM，那你说说类的加载过程吧？ 我们可以自定义一个String类来使用吗？ 什么是类加载器，类加载器有哪些？ 多线程的情况下，类的加载为什么不会出现重复加载的情况？ 什么是双亲委派机制？它有啥优势？可以打破这种机制吗？ 类加载子系统 类加载机制概念 Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的加载机制 。Class文件由类装载器装载后，在JVM中将形成一份描述Class结构的元信息对象，通过该元信息对象可以获知Class的结构信息：如构造函数，属性和方法等，Java允许用户借由这个Class相关的元信息对象间接调用Class对象的功能,这里就是我们经常能见到的Class类。 类加载子系统作用 类加载子系统负责从文件系统或者网络中加载class文件，class文件在文件开头有特定的文件标识（0xCAFEBABE） ClassLoader只负责class文件的加载。至于它是否可以运行，则由Execution Engine决定 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外