xzx18822942899的博客

实际开发过程中，关于树形结构的节点的增删改，都可能影响到它的前驱节点的leaf【是否为叶子节点】，故又统一再服务层封装工具类。在实际的开发过程，经常会使用到树形结构，我的数据库表设计一般都会有这三个字段。id(主键) parent_id（父节点编号） leaf(是否为叶子节点)可以选择反射工具类hutool.ReflectUtil。由于经常使用，故封装了一系列，全套式解决方法的工具类。

前后端分离命名规范：JSON下划线，对象小驼峰，以及Jackson常用配置

像我初学阶段在编码或者项目中都经常用到了线程池却不知道原理，带你手写一个简单线程池，快速了解线程池的工作原理和设计思想。

垃圾收集器没有在规范中进行过多的规定，可以由不同的厂商、不同版本的JVM来实现。由于JDK的版本处于高速迭代过程中，因此Java发展至今已经衍生了众多的GC版本。从不同角度分析垃圾收集器，可以将GC分为不同的类型。Java不同版本新特性语法层面：Lambda表达式、switch、自动拆箱装箱、enum、泛型API层面：Stream API、新的日期时间、Optional、String、集合框架底层优化：JVM优化、GC的变化、元空间、静态域、字符串常量池等。

1、一般的垃圾回收算法至少会划分出两个年代，年轻代和老年代。但是单纯的分代理论在垃圾回收的时候存在一个巨大的缺陷：为了找到年轻代中的存活对象，却不得不遍历整个老年代，反过来也是一样的。2、如果我们从年轻代开始遍历，那么可以断定N, S, P, Q都是存活对象。但是，V却不会被认为是存活对象，其占据的内存会被回收了。这就是一个惊天的大漏洞！因为U本身是老年代对象，而且有外部引用指向它，也就是说U是存活对象，而U指向了V，也就是说V也应该是存活对象才是！而这都是因为我们只遍历年轻代对象！

Java 和 C++语言的区别，就在于垃圾收集技术和内存动态分配上，C++语言没有垃圾收集技术，需要程序员手动的收集。垃圾收集，不是Java语言的伴生产物。早在1960年，第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生。哪些内存需要回收？什么时候回收？如何回收？垃圾收集机制是Java的招牌能力，极大地提高了开发效率。

在调用intern方法时，如果池中已经包含了由equals(object)方法确定的与该字符串内容相等的字符串，则返回池中的字符串地址。如果不是用双引号声明的String对象，可以使用String提供的intern方法：intern方法会从字符串常量池中查询当前字符串是否存在，若不存在就会将当前字符串放入常量池中。2、使用 intern() 方法：由于数组中字符串的引用都指向字符串常量池中的字符串，所以程序需要维护的 String 对象更少，内存占用也更低。常量池就类似一个Java系统级别提供的缓存。

执行引擎是Java虚拟机核心的组成部分之一。“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。JVM的主要任务是负责装载字节码到其内部。

对象实例化的过程：类加载、内存分配、处理并发、属性的默认初始化（0值）、设置对象头信息（类元信息、hashcode、gc消息、锁信息）、属性的显式初始化、代码块中初始化、构造器中初始化;对象的访问定位：句柄访问、直接指针

JVM的方法区与堆、栈的区别；方法区存储内容：已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等；方法区的演进，内容存储，使用内存；BID和NIO概述。

堆针对一个JVM进程来说是唯一的。也就是一个进程只有一个JVM实例，一个JVM实例中就有一个运行时数据区，一个运行时数据区只有一个堆和一个方法区。但是进程包含多个线程，他们是共享同一堆空间的。一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。Java堆区在JVM启动的时候即被创建，其空间大小也就确定了，堆是JVM管理的最大一块内存空间，并且堆内存的大小是可以调节的。《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。

由于跨平台性的设计，Java的指令都是根据栈来设计的。不同平台CPU架构不同，所以不能设计为基于寄存器的【如果设计成基于寄存器的，耦合度高，性能会有所提升，因为可以对具体的CPU架构进行优化，但是跨平台性大大降低】。优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。具体问题具体分析如果只有一个线程才可以操作此数据，则必是线程安全的。如果有多个线程操作此数据，则此数据是共享数据。如果不考虑同步机制的话，会存在线程安全问题。

本节主要讲的是运行时数据区，也就是下图这部分，它是在类加载完成后的阶段当我们通过前面的：类的加载 --> 验证 --> 准备 --> 解析 --> 初始化，这几个阶段完成后，就会用到执行引擎对我们的类进行使用，同时执行引擎将会使用到我们运行时数据区类比一下也就是大厨做饭，我们把大厨后面的东西（切好的菜，刀，调料），比作是运行时数据区。而厨师可以类比于执行引擎，将通过准备的东西进行制作成精美的菜品。

1. 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。2. ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。3. 加载的类信息存放于一块称为方法区的内存空间.

你是否也遇到过这些问题？运行着的线上系统突然卡死，系统无法访问，甚至直接OOM（Out Of Memory：内存溢出）！想解决线上JVM GC（Garbage Collection：垃圾回收）问题，但却无从下手。新项目上线，对各种JVM参数设置一脸茫然，直接默认吧然后就JJ了。每次面试之前都要重新背一遍JVM的一些原理概念性的东西，然而面试官却经常问你在实际项目中如何调优VM参数，如何解决GC、OOM等问题，一脸懵逼。