云原生时代将应用生命周期从"天/月"压缩到"秒"，使 JVM "用时间换性能"的经典设计陷入困境。Java 面临启动慢、内存占用高、预热时间长三大痛点。社区的应对呈现分裂态势：AppCDS 和 CRaC 在保留动态性前提下优化启动；GraalVM Native Image 牺牲部分动态性换取毫秒级启动；Project Leyden 探索中间路线。未来不会有统一解决方案，而是根据场景选择不同技术栈的

本文介绍了一种Spring Boot Fat JAR容器化方案，通过解压归档文件实现分层构建优化。传统容器化方式将整个JAR打包导致缓存效率低下，而本方案利用Fat JAR内部结构(BOOT-INF/lib、classes等目录)进行物理分离，按变更频率分层构建Docker镜像。相比官方分层JAR方案，该方法无需修改项目配置，兼容1.4+所有版本，特别适合无法升级框架或修改构建配置的遗留项目。方案

Native Image 是 Java 在特定云原生场景下的生存手段，不是通用的性能升级方案。启动快、内存省的收益是实打实的。但动态特性受限、监控工具链断裂、Oracle 协议风险、维护复杂度上升，这些代价也是实打实的。对于大多数长生命周期、高吞吐的业务，传统 JVM 加上 AppCDS、CRaC 这些预热优化手段，仍然是性价比最高的选择。Native Image 适合的是那块细分市场：快速响应、

JVM 内存区域分为线程共享区域（方法区、堆）和线程私有区域（虚拟机栈、本地方法栈、程序计数器）。方法区存储类元信息，堆存放对象实例和数组。HotSpot 在 JDK8+ 中用元空间替代永久代，优化了 GC 效率并解决了内存限制问题。虚拟机栈采用栈帧结构管理方法调用，而程序计数器记录线程执行位置。规范定义的是逻辑结构，实际实现（如 HotSpot）会有差异，例如元空间使用本地内存而非 JVM 进程

Minecraft 低资源服务端 JVM 调优指南 本文针对2核4G/4核8G等低配置MC服务器提供JVM调优方案。核心思路是：通过放大Eden区、快速晋升老年代（SurvivorRatio=32+MaxTenuringThreshold=1）、激进并发标记（IHOP=20）和积极内存回收（SoftMaxHeapSize+周期性GC），在有限资源下优化TPS稳定性并降低长尾延迟。提供G1GC和Se

摘要：Java提供了四种引用类型来管理对象生命周期：强引用（默认）、软引用（内存不足时回收）、弱引用（GC直接回收）和虚引用（仅回收通知）。软引用曾用于缓存但因不可预测的回收导致性能问题；弱引用适用于监听器防泄漏和规范化映射；虚引用是finalize的替代方案但不应依赖。作者强调这些引用类型存在诸多问题，除非有明确必要且理解其机制，否则不建议使用，特别是软引用和虚引用在实际应用中存在严重缺陷。

本文介绍了一种Spring Boot Fat JAR容器化方案，通过解压归档文件实现分层构建优化。传统容器化方式将整个JAR打包导致缓存效率低下，而本方案利用Fat JAR内部结构(BOOT-INF/lib、classes等目录)进行物理分离，按变更频率分层构建Docker镜像。相比官方分层JAR方案，该方法无需修改项目配置，兼容1.4+所有版本，特别适合无法升级框架或修改构建配置的遗留项目。方案

java代理模式简介及jdk、cglib动态代理实现方式

云原生时代将应用生命周期从"天/月"压缩到"秒"，使 JVM "用时间换性能"的经典设计陷入困境。Java 面临启动慢、内存占用高、预热时间长三大痛点。社区的应对呈现分裂态势：AppCDS 和 CRaC 在保留动态性前提下优化启动；GraalVM Native Image 牺牲部分动态性换取毫秒级启动；Project Leyden 探索中间路线。未来不会有统一解决方案，而是根据场景选择不同技术栈的

介绍自 java8 以来每个稳定版本都提升了什么新特性