文章标签
jdk
-
你是否遇到过因JDK升级导致的项目崩溃？分享你的经历。
在开发过程中，JDK的升级是一个不可避免的话题，但它带来的潜在问题也不少。例如，我曾经在一个较大的项目中经历了一次JDK升级，导致了项目的全面崩溃。下面是我当时遇到的一些问题以及怎么解决它们的经历。 升级前的准备 当我决定将JDK...
-
JDK 版本升级那些事儿：踩坑指南及最佳实践
JDK 版本升级，说简单也简单，说难也难。简单在于你只需要下载一个新的安装包，然后替换掉旧的 JDK 即可；难在于升级过程中可能遇到的各种兼容性问题、性能问题，甚至导致应用崩溃。 我作为一名老码农，经历过无数次 JDK 版本升级，踩过...
-
如何在不同版本的JDK中实现垃圾回收机制的变更？
在软件开发中，JDK的垃圾回收机制是至关重要的一环，它直接关系到应用程序的性能和内存管理。你是否注意到，不同版本的JDK在实现垃圾回收机制时存在怎样的变更？让我们一起来探索这个问题。 1. 垃圾回收机制的基本概念 在Java中，垃...
-
微服务JVM Young GC耗时飙升？这些工具助你快速定位代码！
线上微服务偶尔出现接口超时，经过初步监控，锁定原因指向 JVM Young GC 耗时瞬间暴增。你描述的这种情况，相信不少在生产环境维护 Java 应用的同行都遇到过，尤其是当 GC 日志量大到难以人工分析时，那种抓耳挠腮的焦虑感，我深有...
-
JDK 17+ 强封装时代：Attach API 与 Instrumentation 的限制与合规应对指南
在 Java 技术的演进历程中， Attach API 和 Instrumentation （Java Agent）一直扮演着“幕后黑客”的角色。无论是 APM 监控（如 SkyWalking）、热部署工具（如 JRebel）、在线诊...
-
Java 21 强封装时代：如何安全使用 Byte Buddy 动态生成类
在 Java 8 时代，使用 Byte Buddy、Cglib 或 Javassist 动态生成类并注入到当前的 ClassLoader 中是一件极其简单且粗暴的事情。大多数库在底层通过反射调用 ClassLoader.defineCl...
-
JDK 21虚拟线程：哪些Native方法会引发Carrier Thread Pinning？如何排查与平替？
在JDK 21中，虚拟线程（Virtual Threads）的引入极大地提升了Java在高并发I/O场景下的吞吐量。然而，虚拟线程并非万能药。当虚拟线程中执行某些特定操作时，它会“钉”在底层的平台线程（Carrier Thread）上，导...
-
深入剖析 Byte Buddy 绕过 JPMS 的强封装：动态模块权限注入的底层原理
自 Java 9 引入 JPMS（Java Platform Module System，Java 模块系统）以来，强封装（Strong Encapsulation）成为了 JVM 安全架构的核心。传统的反射（Reflection）和动态...
-
突破32GB限制：详解ZGC在超大堆（512GB+）下如何应对指针压缩失效与性能衰退
在Java后端架构向大内存、高并发演进的今天，512GB甚至1TB以上的JVM堆内存需求已经屡见不鲜。然而，伴随内存容量跨越 32GB 这一关键门槛，传统的JVM垃圾收集器（如G1、Parallel）都会面临一个致命的性能拐点—— 普通对...
-
Spring Boot 3 整合 Native Memory Tracking (NMT) 监控 JVM 堆外内存并推送到 Grafana
在容器化时代，Java 应用因 OOMKilled 被系统强杀的现象屡见不鲜。很多时候，我们通过 JVM 监控发现堆内存（Heap）还非常充足，但容器的物理内存却已经触顶。这种“幽灵”般的内存泄漏，通常发生在 堆外内存（Off-Heap ...
-
Docker 容器中 JVM 内存限制的最佳实践：彻底告别 cgroup oom-killer
在容器化时代，Java 开发者经常会遇到一个诡异的现象：应用在本地运行得好好的，部署到 Kubernetes 或 Docker 容器后，运行一段时间就会突然消失，没有任何 Java 堆溢出（OutOfMemoryError）的日志，只有容...
-
K8s 中 Java 进程的 G1 与 ZGC 非堆内存开销深度对比：如何避免 Pod 被 OOM Killer 强杀
在 Kubernetes (K8s) 环境中部署 Java 应用时，很多架构师和运维工程师都遭遇过一个诡异的现象： JVM 堆内存（-Xmx）明明设置得离安全水位还有很大距离，但 Pod 依然因为 OOM (Exit Code 137) ...
-
Spring Boot 3 虚拟线程火了，但第三方库的 ThreadLocal 正在悄悄榨干你的内存
在 Spring Boot 3.2+ 中，只需一行配置 spring.threads.virtual.enabled=true ，就能轻松开启 JDK 21 的虚拟线程（Virtual Threads）。这种“高并发神器”允许我们同时运...
0 11 0 0 0 虚拟线程 -
Spring Boot 3 性能调优：手把手教你排查与解决虚拟线程 Pinning（线程固定）难题
在 Spring Boot 3 中，只需一行配置 spring.threads.virtual.enabled=true ，就能轻松开启 Java 21 的虚拟线程（Virtual Threads）。这种“高并发神器”声称能用极低的资源...
-
榨干 JDK 21 性能：Spring Boot 虚拟线程落地实践与压测避坑指南
随着 JDK 21 正式转正虚拟线程（Virtual Threads，即 Project Loom），Java 开发者终于迎来了梦寐以求的“高并发福音”。传统的 Java Web 容器（如 Tomcat）采用的是 Thread-per-r...
-
从Epoll到Continuation：Netty EventLoop与Project Loom内核级调度差异深度解析
在Java高性能网络编程的发展史中，Netty凭借其经典的Reactor线程模型和对OS原生多路复用（Epoll/Kqueue）的极致封装，统治了高性能通信领域长达数十年。然而，随着JDK 21中Project Loom（虚拟线程）的正式...
-
当 io_uring 遇上 Project Loom：彻底瓦解 Epoll 的高并发神话
在过去二十年里，基于 epoll 的反应堆模式（Reactor）统治了 Linux 高性能网络编程。无论是 Nginx、Redis，还是 Java 生态中的 Netty，无一例外都将 epoll 视作高并发的终极解药。 然而，...
-
当JDK升级导致项目崩溃：一次真实的失误与经验教训
在我作为一名软件工程师的职业生涯中，有一次经历让我至今难以忘怀。这是一场看似简单却又意外致命的JDK升级事件。在我们的团队准备将Java Development Kit（JDK）从8版升到11版时，我满怀期待，以为这会带来性能和安全性的显...
-
JVM不同版本对性能的影响：一次深入探究
JVM不同版本对性能的影响：一次深入探究 你是否曾经在项目中遇到过因为JVM版本不同而导致性能差异的问题？或者在升级JDK版本后，发现应用性能反而下降了？相信很多Java开发者都经历过类似的困境。JVM版本对性能的影响是复杂的，它涉及...
-
深度分析JDK8与JDK17垃圾回收机制的差异及对高并发场景的影响
在Java开发中，垃圾回收机制的演变至关重要，尤其是在内存管理和性能方面。本文将深入探讨JDK8与JDK17的垃圾回收机制的差异，并分析其对高并发场景的影响。 JDK8的垃圾回收机制 JDK8引入了几种垃圾回收器，包括串行收集器、...