程序猿进阶

机器宕机或者请求很慢最常出现的几种问题：针对代码bug或者qps过高造成的。【1】cpu过高致内存耗尽OOM，堆区对象回收不及时cpu被打满【2】死锁抢用资源导致cpu过高致耗尽【3】堆内存由于某种原因未释放或无法释放，造成系统内存浪费，严重致宕机（基本上很少）排查过程（推荐第3种）：【1】arthas诊断工具包：线上诊断程序利器，由于arthas包上传不了不符合现在流程所以采用不了。主要用途在于排查程序jvm问题，包版本与预想不一致问题等【2】: 导入dump。

① 如果轻量级锁失败，表示存在竞争，升级为重量级锁（常规锁）；② 在没有锁竞争的情况下，减少传统锁使用。

【1】字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。【2】在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。注意：程序计数器是唯一一个不会出现 OutOfMemoryError 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。

因为 Hotspot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，方法还没有执行，所有的字段都还为零。【1】Hotspot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的自身运行时数据（哈希码、GC分代年龄、锁状态标志等等），另一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是那个类的实例。

时回收该对象，让其超出对象的生命周期范围或者设置引用指向null，并且会执行对象的`finalize 函数。当jvm扫描到虚引用的对象时，会先将此对象放入关联的队列中，因此我们可以通过判断队列中是否存这个对象，来进行回收前的一些处理。认为强引用的对象是用户正在使用的对象，它无法分辨出到底该回收哪个，强行回收有可能导致系统严重错误。强引用是最普遍的引用，一般把一个对象赋给一个引用变量，这个引用变量就是强引用。虚拟机就会把这个软引用加入到与之关联的引用队列中。虚引用和没有引用是一样的，需要和队列。

虚拟机设计团队把类加载阶段中的 “通过一个类的全限定名来获取描述此类的二进制字节流” 这个动作放到 Java虚拟机外部去实现，以便应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。从Java虚拟机的角度上，只存在两种不同的类加载器：一种是，这个类加载器使用C++语言实现，是虚拟机自身的一部分；另外一种就是，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全部继承自。从Java这个类加载器负责将放置在目录中的，或者被。

面试管：在Java中新创建的对象一定是在堆上分配内存吗？如果你的答案是“是的”那就需要看看这个文章了。

业务流量突增，机器直接接入大量流量，和会消耗太多资源，导致1-2分钟时间内的请求超时导致异常，因此采用流量预热的方式，让机器逐步接入流量，需要预热时长。目前服务接入，通过自动扩缩容应用流量变化，当流量激增时，对机器的启动速度带来了挑战，之前通过优化点火时间，已经将机器从容器创建到可接入流量优化到2分钟左右，但3min的预热时长成为了应对流量激增的瓶颈，因此优化机器从接入流量到能稳定服务的时长，目标缩减到2min以内。什么是服务预热： 应用在刚启动的时候处理相应速度会很慢，只有当热点代码执行了一定次数以后，相

JIT与AOT两种不同的编译方式，主要区别在于是否处于运行时进行编译。动态(即时)编译，边运行边编译：在程序运行时，根据算法计算出热点代码，然后进行JIT实时编译，这种方式吞吐量高，有运行时性能加成，可以跑得更快，并可以做到动态生成代码等，但是相对启动速度较慢，并需要一定时间和调用频率才能触发JIT的分层机制。JIT缺点就是编译需要占用运行时资源，会导致进程卡顿。AOT编译能直接将源代码转化为机器码，内存占用低，启动速度快。无需runtime运行，直接将runtime静态链接至最终的程序中，但。

METASPACE 内存溢出问题

Innodb的行锁是通过给索引的索引项加锁来实现的

JVM 启动参数规则整理

G1 GC（Garbage-First Garbage Collector）通过 -XX:+UseG1GC参数来启用，在JDK 7 被正式推出，相信熟悉 JVM的同学们都不会对它感到陌生。在 JDK 9中，G1被提议设置为默认垃圾收集器（JEP 248）。在官网中，是这样描述G1的：The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines wit

Thread Dump介绍Thread Dump是非常有用的诊断 Java应用问题的工具。每一个 Java虚拟机都有及时生成所有线程在某一点状态的 thread-dump的能力，虽然各个 Java虚拟机打印的 thread dump略有不同，但是大多都提供了当前活动线程的快照，及 JVM中所有 Java线程的堆栈跟踪信息，堆栈信息一般包含完整的类名及所执行的方法，如果可能的话还有源代码的行数。Thread Dump特点：【1】能在各种操作系统下使用；【2】能在各种 Java应用服务器下使用；【

Arthas（阿尔萨斯） 是 Alibaba开源的 Java诊断工具，深受开发者喜爱。当遇到以下类似问题而束手无策时，Arthas 可以帮助你解决：【1】这个类从哪个 jar 包加载的? 为什么会报各种类相关的 Exception?【2】我改的代码为什么没有执行到? 难道是我没 commit? 分支搞错了?【3】遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗?【4】线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！【5】是否有一个全局视角来查看系统.

在分享此案例前，先聊聊哪些场景会导致频繁Full GC：内存泄漏（代码有问题，对象引用没及时释放，导致对象不能及时回收）死循环大对象程序执行了System.gc()尤其是大对象，80%以上的情况就是他。 那么大对象从哪里来的：【1】数据库（包括 Mysql和 Mongodb等 NOSql数据库），结果集太大；【2】第三方接口传输的大对象；【3】消息队列，消息太大；根据多年一线互联网经验，绝大部分情况是数据库大结果集导致。好，现在我们开始介绍这次线上故障：在没有任何发布的.

1. Java 堆空间发生频率：5颗星造成原因 无法在 Java 堆中分配对象 吞吐量增加 应用程序无意中保存了对象引用，对象无法被 GC 回收 应用程序过度使用 finalizer。finalizer 对象不能被 GC 立刻回收。finalizer 由结束队列服务的守护线程调用，有时 finalizer 线程的处理能力无法跟上结束队列的增长 解决方案单位对应：GB -> G, g；MB -> M, m；KB -> K...

计算机是不能直接运行 java代码的，必须要先运行 java虚拟机，再由java虚拟机运行编译后的 java代码。这个编译后的 java代码，就是本文要介绍的java字节码。计算机截止目前只认识0和1，但虚拟机以及大量建立在虚拟机之上的程序语言如雨后春笋般出现并蓬勃发展，将我们编写的程序编译成二进制本地机器码(Native Code)已不再是唯一的选择，越来越多的程序选择与操作系统和机器指令集无关的、平台中立的格式作为程序编译后的存储格式。实现语言无关性的基础仍然是虚拟机和字节码存储格式。Java虚拟机

Java 开发人员肯定都知道 JDK的 bin 目录中有 “java.exe”、“javac.exe” 这两个命令行工具。下面主要介绍一些监视虚拟机和故障处理的工具。Jvm 入门工具jps（JavaVirtual Machine Process Status Tool）：jps是 JDK提供的一个查看当前 Java进程的小工具。显示指定系统内所有的 HotSpot 虚拟机进程。jps常用命令：格式为 jps [options] [hostid] ，jps 可以通过 RMI协议查询开启了 RM

一、什么情况下会发生栈内存溢出【1】线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常。递归的调用一个简单的方法，不断累积就会抛出 StackOverflowError 异常。【2】如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出 OutOfMemoryError 异常。无限循环的创建线程，并对每个线程增加内存。则会抛出 OutOfMemoryError 异常。【注意】：在多线程的情况下，给每个线程的栈分配的内存越大，越容易产生内存溢出异常。操作系统为

Java对象存储在堆（Heap）内存。那么一个 Java对象到底包含什么呢？概括起来分为对象头、对象体和对齐字节。如下图所示：Mark Word（标记字）以上是 Java对象处于5种不同状态时，Mark Word中 64位的表现形式，上面每一行代表对象处于某种状态时的样子。其中各部分的含义如下：【1】lock：2位的锁状态标记位，由于希望用尽可能少的二进制位表示尽可能多的信息，所以设置了 lock标记。该标记的值不同，整个 Mark Word表示的含义不同。biased_lock 和 lock一

ZGC（The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器，它的设计目标包括：【1】停顿时间不超过10ms；【2】停顿时间不会随着堆的大小，或者活跃对象的大小而增加，影响它的是 GCRoot对象；【3】支持 8MB~4TB级别的堆（未来支持16TB）；从设计目标来看，ZGC适用于大内存低延迟服务的内存管理和回收。本文主要介绍 ZGC在低延时场景中的应用和卓越表现，文章内容主要分为四部分：【1】GC之痛：介绍实际业务中遇到的 GC痛点，并分析 CMS收集器和