<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[wuminyu的博客]]></title><description><![CDATA[研究领域：Linux系统内核、C/C++后端开发、Java全栈开发等。
座右铭："物有本末，事有终始，知其先后，则近道矣。" 这句话出自《大学》，是儒家经典中关于修身、处事的重要论述。]]></description><link>https://blog.csdn.net/wuminyu</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; wuminyu]]></copyright><item><title><![CDATA[JDK21中ObjectMonitor的异步回收机制原理剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/166093842</link><guid>https://blog.csdn.net/wuminyu/article/details/166093842</guid><author>wuminyu</author><pubDate>Sun, 20 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文分析了JDK 21 引入异步 Monitor 回收（Async Deflation），由 MonitorDeflationThread 主导，摆脱 GC Safepoint 依赖。通过定时检测与压力触发，结合 ZGC/Shenandoah 并发标记阶段，实现无锁三阶段降级：哨兵标记、Mark Word 还原、监控器归还池。基于 is_busy() 精确判断空闲状态，确保线程安全。该机制显著降低锁开销，提升高并发场景性能。]]></description><category></category></item><item><title><![CDATA[JDK21中多线程竞争导致ObjectMonitor的CAS状态转移逻辑剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165966521</link><guid>https://blog.csdn.net/wuminyu/article/details/165966521</guid><author>wuminyu</author><pubDate>Sat, 19 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文剖析JDK21中多线程竞争导致ObjectMonitor CAS状态转移的机制。在轻量锁膨胀过程中，多个线程并发触发inflate_impl，通过CAS原子操作竞争挂载ObjectMonitor。成功者将Mark Word更新为Inflated状态并返回监控器；失败者释放预分配的Monitor并自旋重试，复用已膨胀的实例。整个过程依赖Mark Word状态机演进：从Unlocked→INFLATING→Inflated，确保唯一性与无锁一致性，避免内存泄漏，保障高并发下锁膨胀的安全与高效。]]></description><category></category></item><item><title><![CDATA[JDK21中ObjectMonitor膨胀机制剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165836851</link><guid>https://blog.csdn.net/wuminyu/article/details/165836851</guid><author>wuminyu</author><pubDate>Fri, 18 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文剖析了JDK 21中，当递归锁深度超过LockStack容量（8次）时，C2编译器通过边界检查（jge指令）强制跳转至慢速路径，触发锁膨胀。LightweightSynchronizer::enter检测到栈满后调用inflate_and_enter，由ObjectSynchronizer::inflate分配ObjectMonitor，并将对象头标记为Inflated状态。此后，嵌套锁不再依赖LockStack，而是由ObjectMonitor维护重入计数与等待队列，实现轻量级锁向重量级锁的平滑过渡。]]></description><category></category></item><item><title><![CDATA[纯轻量级锁体系下C2编译器锁粗化和消除机制剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165705624</link><guid>https://blog.csdn.net/wuminyu/article/details/165705624</guid><author>wuminyu</author><pubDate>Thu, 17 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文剖析分析了在JDK 21+纯轻量级锁（LockStack）体系下，C2编译器的锁消除与粗化机制实现根本性重构。锁消除彻底移除物理栈槽，实现零开销；锁粗化则同步消除CAS指令与线程局部LockStack写入，收益显著提升。解优化时通过线程私有栈重压锁状态，无需恢复Displaced Mark Word。整体优化从“逻辑剥离”迈向“物理清零”，大幅降低多线程场景下的内存与指令开销。]]></description><category></category></item><item><title><![CDATA[Markword在紧凑对象头上的实现原理剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165575288</link><guid>https://blog.csdn.net/wuminyu/article/details/165575288</guid><author>wuminyu</author><pubDate>Wed, 16 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文剖析JDK 21中Mark Word在紧凑对象头下的实现原理。传统轻量级锁通过覆写Mark Word存储栈指针，导致类指针（nKlass）被破坏，阻碍对象头压缩。JDK 21引入Thread-Local LockStack机制，将锁状态由线程私有栈维护，Mark Word仅修改低2位锁状态位，原位保留nKlass、HashCode与年龄信息，彻底解耦锁与对象头，实现高效、可扩展的紧凑对象头布局。]]></description><category></category></item><item><title><![CDATA[Hotspot编译器对连续的synchronized块进行锁优化原理剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165431907</link><guid>https://blog.csdn.net/wuminyu/article/details/165431907</guid><author>wuminyu</author><pubDate>Tue, 15 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[HotSpot C2编译器通过锁粗化优化连续synchronized块：在IR图中识别同一对象的相邻加锁/解锁节点对，利用GVN阶段进行对象引用匹配与拓扑分析，将冗余锁操作合并为单一临界区。核心机制基于AbstractLockNode抽象类的Coarsened标记，结合指针分析与别名判断确保对象同一性，最终在PhaseMacroExpand阶段裁撤中间锁节点，减少锁开销，提升并发性能。]]></description><category></category></item><item><title><![CDATA[Hotspot消除不必要volatile和lock指令原理剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165280237</link><guid>https://blog.csdn.net/wuminyu/article/details/165280237</guid><author>wuminyu</author><pubDate>Mon, 14 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文剖析Hotspot JVM中消除不必要的volatile与lock指令的原理。通过逃逸分析判定对象是否“不逃逸”（NoEscape），若成立，则在C2编译器的宏展开阶段移除同步锁节点（如FastLock/FastUnlock），并通过disconnect_projections直接连接控制流与内存流，实现锁消除。同时，对volatile变量的内存屏障（如MemBarNode）也基于逃逸分析进行优化，移除非必要屏障。最终生成无锁、无冗余内存屏障的高效机器码，提升并发性能。]]></description><category></category></item><item><title><![CDATA[Kafka中sendfile与mmap实现机制解析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165186359</link><guid>https://blog.csdn.net/wuminyu/article/details/165186359</guid><author>wuminyu</author><pubDate>Sun, 13 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文解析Kafka中sendfile与mmap的I/O机制。传统read/write存在4次上下文切换和2次CPU拷贝，性能低下；而sendfile通过内核直连文件与套接字，实现零拷贝，仅需2次上下文切换与2次DMA拷贝，显著提升吞吐。Kafka利用sendfile在FileChannelImpl.transferTo中透传至内核，高效传输日志数据。mmap虽支持内存映射读写，但发送时仍需一次CPU拷贝。二者结合优化了高并发场景下的数据传输效率。]]></description><category></category></item><item><title><![CDATA[Kafka配置TLS/SSL加密传输时零拷贝失效分析]]></title><link>https://blog.csdn.net/wuminyu/article/details/165081306</link><guid>https://blog.csdn.net/wuminyu/article/details/165081306</guid><author>wuminyu</author><pubDate>Sat, 12 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[Kafka启用TLS/SSL加密后，因协议要求数据需经加密、分块与封装，破坏了sendfile零拷贝的同构性假设，导致内核无法直接将磁盘页缓存通过DMA传输至网卡。源码显示，SSL模式下SslTransportLayer强制降级为用户态read-encrypt-write流程，引发四次内存拷贝与高CPU开销，致使性能急剧下降，零拷贝机制失效。]]></description><category></category></item><item><title><![CDATA[Kafka的写入延迟与磁盘IO抖动原理分析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164952289</link><guid>https://blog.csdn.net/wuminyu/article/details/164952289</guid><author>wuminyu</author><pubDate>Fri, 11 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文分析Kafka写入延迟与磁盘IO抖动的根源，揭示其背后Linux内核的脏页写回机制。当Kafka在大内存环境下使用默认参数时，内核基于vm_dirty_ratio等参数动态计算脏页阈值，触发前台强制限流（Direct Throttling）——导致balance_dirty_pages()阻塞Kafka线程，引发P99/P999延迟飙升、Follower脱离ISR及磁盘I/O爆发。核心在于三区控制模型：自由写入区、后台刷盘区与前台限流区，其中高脏页水位迫使进程休眠数秒，严重破坏Kafka低延迟特性。]]></description><category></category></item><item><title><![CDATA[Kafka利用sendfile与Page Cache实现高性能传输剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164801633</link><guid>https://blog.csdn.net/wuminyu/article/details/164801633</guid><author>wuminyu</author><pubDate>Thu, 10 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文剖析Kafka通过将消息缓存交由操作系统Page Cache，并结合sendfile零拷贝机制，实现高性能传输。其核心在于：1）摒弃JVM堆内存缓存，避免GC停顿与内存开销；2）统一二进制格式，实现“零转换”；3）利用sendfile在内核态直接将Paache数据经SG-DMA直送网卡，减少上下文切换与CPU拷贝，显著降低延迟、提升吞吐。该设计使Kafka在高并发场景下具备接近原生性能的写读能力。]]></description><category></category></item><item><title><![CDATA[Netty网络发送优化原理解析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164709632</link><guid>https://blog.csdn.net/wuminyu/article/details/164709632</guid><author>wuminyu</author><pubDate>Wed, 09 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[Netty通过netty-transport-native-epoll模块，利用JNI直接调用Linux原生epoll和Socket API，结合SO_ZEROCOPY与MSG_ZEROCOPY实现CPU零拷贝。发送时，DirectByteBuf内存地址经send系统调用锁定物理页，由网卡DMA直接读取，避免数据拷贝。内核通过EPOLLERR异步通知完成，Netty释放内存池。零拷贝启用需在Socket初始化时配置，且数据量需≥16KB以避免额外开销。]]></description><category></category></item><item><title><![CDATA[JVM零拷贝实现机制解析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164562735</link><guid>https://blog.csdn.net/wuminyu/article/details/164562735</guid><author>wuminyu</author><pubDate>Tue, 08 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文解析JVM零拷贝机制，核心为DirectBuffer与DMA协同。传统I/O需4次数据拷贝和4次上下文切换，CPU拷贝占用资源。HeapByteBuffer因GC移动地址无法直接DMA，需临时拷贝至DirectBuffer。DirectBuffer在C-Heap分配固定内存，通过Unsafe保存Native地址，系统调用直接传递指针，避免内核-用户态二次拷贝，实现高效数据传输。]]></description><category></category></item><item><title><![CDATA[NIO基于epoll和io_uring在上下文切换与CPU利用率差异分析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164450093</link><guid>https://blog.csdn.net/wuminyu/article/details/164450093</guid><author>wuminyu</author><pubDate>Mon, 07 Sep 2026 13:15:00 +0800</pubDate><description><![CDATA[本文对比JDK NIO(epoll)与io_uring的架构差异：epoll基于就绪通知，每次I/O周期需多次系统调用（epoll_wait+read/write），在C1000K高并发下上下文切换代价高；io_uring基于异步完成，通过mmap共享SQ/CQ环形队列，SQPOLL模式可实现零系统调用，显著减少上下文切换并提升CPU利用率。文章结合源码剖析了epoll的性能瓶颈，凸显io\_uring在CPU利用率和并发处理上的优势。]]></description><category></category></item><item><title><![CDATA[JVM内存屏障简介]]></title><link>https://blog.csdn.net/wuminyu/article/details/164422506</link><guid>https://blog.csdn.net/wuminyu/article/details/164422506</guid><author>wuminyu</author><pubDate>Sun, 06 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文介绍了JVM内存屏障的硬件基础与实现原理：从CPU多核缓存一致性（MESI协议）出发，解释了Store Buffer和Invalidate Queue如何引入乱序执行，进而引出JMM四种逻辑屏障（LoadLoad、StoreStore、LoadStore、StoreLoad）及HotSpot的OrderAccess抽象。并以volatile读写为例，展示了字节码解释器中屏障的插入与x86下的具体落地。]]></description><category></category></item><item><title><![CDATA[Linux内核线程调度与虚拟线程调度机制系统级深度剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164394849</link><guid>https://blog.csdn.net/wuminyu/article/details/164394849</guid><author>wuminyu</author><pubDate>Sat, 05 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文系统剖析Linux内核线程与Project Loom虚拟线程调度机制。传统平台线程采用1:1模型，经pthread_create→clone系统调用映射至内核task_struct，共享地址空间，存在内存足迹大、上下文切换开销高、调度竞争等瓶颈。Loom引入M:N虚拟线程，通过Continuation机制实现用户态调度，降低系统资源消耗，提升并发扩展性。文章结合OpenJDK源码与内核结构，深度对比两种模型的实现路径与性能差异。]]></description><category></category></item><item><title><![CDATA[JVM锁膨胀与Futex源码解析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164358972</link><guid>https://blog.csdn.net/wuminyu/article/details/164358972</guid><author>wuminyu</author><pubDate>Fri, 04 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文解析JVM锁膨胀机制，详述Mark Word位域布局及锁状态（无锁、偏向锁、轻量锁、重量锁）的编码，结合HotSpot源码分析monitorenter快速与慢速路径，并阐明锁膨胀至重量级时ObjectMonitor的分配与Futex关联。]]></description><category></category></item><item><title><![CDATA[JVM堆外与Native内存分配原理]]></title><link>https://blog.csdn.net/wuminyu/article/details/164323639</link><guid>https://blog.csdn.net/wuminyu/article/details/164323639</guid><author>wuminyu</author><pubDate>Thu, 03 Sep 2026 13:30:00 +0800</pubDate><description><![CDATA[JVM堆外与Native内存分配是绕过Java堆管理的核心机制。DirectByteBuffer通过Unsafe.allocateMemory在Native堆中malloc内存，由Cleaner异步释放。其分配受MaxDirectMemorySize限制，超限时触发System.gc()及Reference处理。HotSpot底层封装libc的malloc，并通过NMT追踪内存来源。本文解析了从Java层调用到C++实现的完整路径，对比了堆内GC与堆外手动回收的差异，强调堆外内存管理的精度与潜在泄漏风险。]]></description><category></category></item><item><title><![CDATA[静态大页与透明大页在TLB hit 上的提升与内存碎片风险]]></title><link>https://blog.csdn.net/wuminyu/article/details/164287930</link><guid>https://blog.csdn.net/wuminyu/article/details/164287930</guid><author>wuminyu</author><pubDate>Wed, 02 Sep 2026 13:00:00 +0800</pubDate><description><![CDATA[本文对比静态大页与透明大页在TLB命中提升上的原理：大页减少页表层级、扩大TLB覆盖范围。静态大页预分配锁定，性能稳定但存在内部碎片；透明大页依赖内核动态合并，易引发内存碎片及Direct Compaction导致的高延迟Jitter，性能波动大。JVM场景下，静态大页更可控，透明大页需权衡碎片风险。]]></description><category></category></item><item><title><![CDATA[JVM虚拟内存状态演进剖析]]></title><link>https://blog.csdn.net/wuminyu/article/details/164252843</link><guid>https://blog.csdn.net/wuminyu/article/details/164252843</guid><author>wuminyu</author><pubDate>Tue, 01 Sep 2026 14:00:00 +0800</pubDate><description><![CDATA[本文剖析JVM与操作系统协作下的虚拟内存状态演进：从Unmapped（未映射）经mmap(PROT_NONE)转为Reserved（仅注册VMA），再通过mprotect升级为Committed（仍未分配物理页），最终在写入时触发缺页中断，建立PTE映射并增加RSS。基于HotSpot源码，详解ReservedSpace与os::pd_reserve_memory的底层实现，揭示各阶段页表与物理内存变化。]]></description><category></category></item></channel></rss>