李哈zzz的博客

在看到Saturn唯品会的分布式调度框架时，看到此框架使用了信号处理，并且外面关于Java信号处理机制的文章很少有写到JVM层面，所以笔者心血来潮写下了这篇关于Java信号处理机制的文章～因为Java信号处理机制是依赖于底层操作系统的信号处理机制，本文重点关注于Java信号处理机制，所以并不会过度的去介绍操作系统的信号处理机制～

在Linux和mac操作系统上当开发者运行Java程序（当然不限于Java程序）想停止结束进程时一般都使用ctrl+c或者kill -9 进程号来结束。那么肯定会有开发者对ctrl+c为什么能结束JVM进程感到兴趣，所以笔者写在了这篇关于ctrl+c结束JVM进程的文章，带领各位读者研究为什么ctrl+c能结束，以及看了源码后得到的一些 " 有趣 " 的事情～本文讲解了JVM使用信号机制优雅的关闭JVM，也讲解了如何使用Java信号机制把JVM默认的信号处理函数给替换导致JVM无法正常关闭～

在Java类库中很多类都有一个registerNatives的native方法，并且写在static静态代码块中进行初始化调用，有不少的读者应该会对这个方法感兴趣，但是此方法是一个native方法，让不少的读者望而却步，所以笔者写在这一篇关于registerNatives方法的文章～

笔者看了很多关于HashCode文章，发现大家很多都是" 面试宝典 " 的内容照搬，这对于喜欢底层研究的程序员来说不是好事，所以在这种情况下促使我写下这篇关于hashCode的文档。hashCode 作为一个native方法定义在Object类中，方法上给出了方法的注释和定义。Returns:See Also:此方法返回一个整数的hash码，此方法提供给HashMap类使用此方法在同一对象上多次调用都返回同一个hash码。

首先，笔者先吐槽一下RocketMQ的官方，源码中啥注释都没有，虽然文档给的多，但是很多都是版本过时不及时更新，阅读者只能靠自己的强硬的技术去理解~回归正题，如今互联网的技术离不开微服务、分布式的体系，所以在分布式的体系中如何创建一个全局唯一的ID是大家所面对的问题。现大厂都提出了解决方案：Twitter的雪花算法（Snowflake）、美团的Leaf算法、以及Mysql、Redis 这种自带原子性操作的中间件。

对于大大大大大大部分Java业务场景来说都是强引用，基本上不会使用到软、弱、虚引用。而在JDK1.2推出的软、弱、虚引用大部分出现场景都是在缓存中，在JDK类库ThreadLocal、WeakHashMap。框架：Mybatis、Netty、以及各种缓存框架等等。至于为什么要用在缓存中呢，也很好理解，因为这些引用实际上可有可无，完美契合于缓存，在有的时候给系统加速，在系统内存紧张的时候清除缓存给核心业务使用。

大部分的Java程序员知道让线程睡眠的方法是Thread.sleep方法，而这个方法是一个native方法，让很多想知道底层如何让线程睡眠的程序员望而却步。所以笔者特意写在这篇文章，带各位读者剖析一下Thread.sleep方法背后的神秘。sleep的底层实现并不复杂，但是不看源码是不会知道，如果传入的时间为0会优化成yield方法，并且在底层并不会像Object类中wait方法一样，释放锁资源等等～

对于Java线程的创建这个话题，似乎已经被"八股文"带偏～ 大部分Java程序员从"八股文"得知创建Java线程有N种方式，比如new Thread、new Runnable、Callable、线程池等等～ 而笔者写下这篇文章的目的是让大家从JVM源码的层面知道创建一个Java线程的方式。

在各种论坛上，笔者看到大部分的博客都是把netty的IdleStateHandler说成心跳机制，而笔者认为这并不是心跳机制，仅仅是跟心跳机制比较相似，并且IdleStateHandler能做的并不仅仅只有"心跳机制"，笔者认为叫做空闲检测机制比较适合。为什么说叫做空闲检测机制比较合适呢？因为netty是封装了NIO，而提及IO无非就是输入输出，换种方式说无非就是读和写。

在上篇文章中讲述了PriorityQueue优先级队列，它底层由小顶堆实现（完全二叉树），在插入元素的时候需要向上调整（siftUp），在取出元素的时候需要向下调整（siftDown），调整的过程是非常浪费性能，尤其是数据量过多的时候。而时间轮通过O1的时间复杂度直接定位在哪一块上，如果有冲突就使用链表把定位在同一块的任务链起来，不需要任何的调整，整体效率比小顶堆高，尤其是数据量大的时候差距就更加的明显～

在数据结构中，队列分为FIFOLIFO两种模型，分别为先进先出，后进后出先进后出，后进先出（栈）而一切数据结构都是基于数组或者是链表实现。在Java中，定义了Queue接口，接口中定义了CRUD的基本方法。分别add、offer、remove、poll等等，而PriorityQueue 实现此接口实现了基本的CRUD的同时拥有了自己的特性，从名字来看也能知道是优先级队列 ： 保持队列头部节点是整条队列中永远是最小或者最大的节点，其实现原理就是一个小顶堆或者大顶堆。上文提及到。

一个操作系统对于内存的管理是非常的重要，关乎到整个系统的运行效率和内存最大使用率。内存管理从宏观来看，无非就是使内存达到最大使用率，减少内存的内/外碎片。而在Linux内核中使用伙伴算法（Buddy）管理一组页，使用Slab算法管理单独页，伙伴算法+Slab算法合理的避免内存的内/外碎片。那么今天介绍的kmem_cache_create方法就是Slab算法。

FastThreadLocal完全是O1时间复杂度，不过是空间换时间罢了，存在一定的内存浪费（尤其是项目中大量使用FastThreadLocal，每个线程的InternalThreadLocalMap会越来越大，浪费会越来越多，不过，如今内存不值钱，用很小很小一部分内存换取执行效率是值得的～！

为什么写下这篇文章，因为在实际项目中，是无法避免TCP通讯（对于这点，可能大部分Java程序员感受不到底层的网络通讯），正因为无法避免TCP通讯，恰好TCP通讯存在三次握手和四次挥手的过程，如果建立一次连接就三次握手和四次挥手，而我们清楚的知道三次握手和四次挥手是同步的过程，此过程也会带来不少的时间浪费和资源的浪费。所以Linux内核TCP网络协议栈就出现了KeepAlive机制，此机制减少三次握手和四次挥手次数，第一次建立连接后保持长连接，后续通讯就可以只考虑发送数据报文即可。往往出现一个机制解决某个问题

最近在群里看到有一位老哥拿着异常信息到处问，而发生的就是java.lang.OutOfMemoryError: GC overhead limit exceeded异常，恰好看到经常有人询问关于这个异常的问题，如何发生的，要如何解决呢？所以促使我写下这篇文章，此文章分为3大块，出现的原因，如何解决，源码论证。

System.getProperty 方法大家并不陌生，在各大框架源码中都能见到，项目中也能使用到，那么此篇文章将带你揭开System.getProperty方法底层实现。System.getProperty 可以拿到当前系统属性，比如当前操作系统的属性、动态链接库位置、编码集、当前虚拟机的版本等等一系列系统属性。当然，你可以把它理解为整个系统上下文的一个存储数据的集合，你可以往里面set属性，任何地点get取出，并且线程安全。下面案例是展示了默认情况下所有的属性（所有的key都展示出来了，项目中如需使

最近，有一位网友询问关于Java命令行参数方面的问题，因为在Java中参数有很多种，有不少的读者一直没弄明白，所以特意写下此篇文章。此篇文章分2大块，第一块是不同参数的解释，第2块就是JVM源码论证～图1-1给出了运行Java代码的命令行，其中包括了启动命令和不同种类的参数，分别用红、黄、黑、绿、蓝、粉 6种颜色代表。

Hotspot中执行引擎分为解释器、JIT及时编译器，上篇文章描述到解释器过度到JIT的条件。[JVM源码剖析之达到什么条件进行JIT优化](https://blog.csdn.net/qq_43799161/article/details/131831105?spm=1001.2014.3001.5501) 这篇文章大致讲述JIT的编译过程。在JDK中javac和JIT两部分跟编译原理挂钩，而编译原理抛开内部实现的算法，从思想的角度出发可以分为前端、中间IR、后端，见图1.1描述。比如拿javac举例，开

在Hotspot虚拟机中执行引擎包括解释器、JIT及时编译器。从" Hotspot" 这个单词也能看出，此虚拟机为了热点而生。Hotspot虚拟机默认允许2大执行引擎同时进行工作，在正常情况下使用解释器进行工作，当达到一定阈值后从解释器转为JIT编译器工作（PS：当然，一切都可由开发者高度配置，比如：只允许解释器，比如转换阈值变低等等，为了篇幅，这里并不会把配置参数提供出来）

JVM是一个运行在操作系统上的虚拟机。因为是一台虚拟的机器，所以对于内存肯定是可以控制的，恰好JVM提供了众多个参数控制内部运行时，而Xms和Xmx两个参数是用来控制Java堆内存的最小内存和最大内存。可能不少读者会好奇Xms和Xmx两个参数能够设置的最小值是多少，所以笔者借助源码来简单论述～答案先放在这里JDK8JDK12。