mirror of
https://github.com/zhwei820/learn.lianglianglee.com.git
synced 2025-09-25 20:56:42 +08:00
370 lines
25 KiB
HTML
370 lines
25 KiB
HTML
<!DOCTYPE html>
|
||
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
|
||
<link rel="icon" href="/static/favicon.png">
|
||
<title>10 双刃剑：合理管理 Netty 堆外内存.md.html</title>
|
||
<!-- Spectre.css framework -->
|
||
<link rel="stylesheet" href="/static/index.css">
|
||
<!-- theme css & js -->
|
||
<meta name="generator" content="Hexo 4.2.0">
|
||
</head>
|
||
<body>
|
||
<div class="book-container">
|
||
<div class="book-sidebar">
|
||
<div class="book-brand">
|
||
<a href="/">
|
||
<img src="/static/favicon.png">
|
||
<span>技术文章摘抄</span>
|
||
</a>
|
||
</div>
|
||
<div class="book-menu uncollapsible">
|
||
<ul class="uncollapsible">
|
||
<li><a href="/" class="current-tab">首页</a></li>
|
||
</ul>
|
||
<ul class="uncollapsible">
|
||
<li><a href="../">上一级</a></li>
|
||
</ul>
|
||
<ul class="uncollapsible">
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/00 学好 Netty，是你修炼 Java 内功的必经之路.md.html">00 学好 Netty，是你修炼 Java 内功的必经之路</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/01 初识 Netty：为什么 Netty 这么流行？.md.html">01 初识 Netty：为什么 Netty 这么流行？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/02 纵览全局：把握 Netty 整体架构脉络.md.html">02 纵览全局：把握 Netty 整体架构脉络</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/03 引导器作用：客户端和服务端启动都要做些什么？.md.html">03 引导器作用：客户端和服务端启动都要做些什么？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/04 事件调度层：为什么 EventLoop 是 Netty 的精髓？.md.html">04 事件调度层：为什么 EventLoop 是 Netty 的精髓？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/05 服务编排层：Pipeline 如何协调各类 Handler ？.md.html">05 服务编排层：Pipeline 如何协调各类 Handler ？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/06 粘包拆包问题：如何获取一个完整的网络包？.md.html">06 粘包拆包问题：如何获取一个完整的网络包？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/07 接头暗语：如何利用 Netty 实现自定义协议通信？.md.html">07 接头暗语：如何利用 Netty 实现自定义协议通信？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/08 开箱即用：Netty 支持哪些常用的解码器？.md.html">08 开箱即用：Netty 支持哪些常用的解码器？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/09 数据传输：writeAndFlush 处理流程剖析.md.html">09 数据传输：writeAndFlush 处理流程剖析</a>
|
||
</li>
|
||
<li>
|
||
<a class="current-tab" href="/专栏/Netty 核心原理剖析与 RPC 实践-完/10 双刃剑：合理管理 Netty 堆外内存.md.html">10 双刃剑：合理管理 Netty 堆外内存</a>
|
||
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/11 另起炉灶：Netty 数据传输载体 ByteBuf 详解.md.html">11 另起炉灶：Netty 数据传输载体 ByteBuf 详解</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/12 他山之石：高性能内存分配器 jemalloc 基本原理.md.html">12 他山之石：高性能内存分配器 jemalloc 基本原理</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/13 举一反三：Netty 高性能内存管理设计（上）.md.html">13 举一反三：Netty 高性能内存管理设计（上）</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/14 举一反三：Netty 高性能内存管理设计（下）.md.html">14 举一反三：Netty 高性能内存管理设计（下）</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/15 轻量级对象回收站：Recycler 对象池技术解析.md.html">15 轻量级对象回收站：Recycler 对象池技术解析</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/16 IO 加速：与众不同的 Netty 零拷贝技术.md.html">16 IO 加速：与众不同的 Netty 零拷贝技术</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/17 源码篇：从 Linux 出发深入剖析服务端启动流程.md.html">17 源码篇：从 Linux 出发深入剖析服务端启动流程</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/18 源码篇：解密 Netty Reactor 线程模型.md.html">18 源码篇：解密 Netty Reactor 线程模型</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/19 源码篇：一个网络请求在 Netty 中的旅程.md.html">19 源码篇：一个网络请求在 Netty 中的旅程</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/20 技巧篇：Netty 的 FastThreadLocal 究竟比 ThreadLocal 快在哪儿？.md.html">20 技巧篇：Netty 的 FastThreadLocal 究竟比 ThreadLocal 快在哪儿？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/21 技巧篇：延迟任务处理神器之时间轮 HashedWheelTimer.md.html">21 技巧篇：延迟任务处理神器之时间轮 HashedWheelTimer</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/22 技巧篇：高性能无锁队列 Mpsc Queue.md.html">22 技巧篇：高性能无锁队列 Mpsc Queue</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/23 架构设计：如何实现一个高性能分布式 RPC 框架.md.html">23 架构设计：如何实现一个高性能分布式 RPC 框架</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/24 服务发布与订阅：搭建生产者和消费者的基础框架.md.html">24 服务发布与订阅：搭建生产者和消费者的基础框架</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/25 远程通信：通信协议设计以及编解码的实现.md.html">25 远程通信：通信协议设计以及编解码的实现</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/26 服务治理：服务发现与负载均衡机制的实现.md.html">26 服务治理：服务发现与负载均衡机制的实现</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/27 动态代理：为用户屏蔽 RPC 调用的底层细节.md.html">27 动态代理：为用户屏蔽 RPC 调用的底层细节</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/28 实战总结：RPC 实战总结与进阶延伸.md.html">28 实战总结：RPC 实战总结与进阶延伸</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/29 编程思想：Netty 中应用了哪些设计模式？.md.html">29 编程思想：Netty 中应用了哪些设计模式？</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/30 实践总结：Netty 在项目开发中的一些最佳实践.md.html">30 实践总结：Netty 在项目开发中的一些最佳实践</a>
|
||
</li>
|
||
<li>
|
||
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/31 结束语 技术成长之路：如何打造自己的技术体系.md.html">31 结束语 技术成长之路：如何打造自己的技术体系</a>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
|
||
<div class="sidebar-toggle-inner"></div>
|
||
</div>
|
||
<script>
|
||
function add_inner() {
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
inner.classList.add('show')
|
||
}
|
||
function remove_inner() {
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
inner.classList.remove('show')
|
||
}
|
||
function sidebar_toggle() {
|
||
let sidebar_toggle = document.querySelector('.sidebar-toggle')
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
let content = document.querySelector('.off-canvas-content')
|
||
if (sidebar_toggle.classList.contains('extend')) { // show
|
||
sidebar_toggle.classList.remove('extend')
|
||
sidebar.classList.remove('hide')
|
||
content.classList.remove('extend')
|
||
} else { // hide
|
||
sidebar_toggle.classList.add('extend')
|
||
sidebar.classList.add('hide')
|
||
content.classList.add('extend')
|
||
}
|
||
}
|
||
function open_sidebar() {
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
sidebar.classList.add('show')
|
||
overlay.classList.add('show')
|
||
}
|
||
function hide_canvas() {
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
sidebar.classList.remove('show')
|
||
overlay.classList.remove('show')
|
||
}
|
||
</script>
|
||
<div class="off-canvas-content">
|
||
<div class="columns">
|
||
<div class="column col-12 col-lg-12">
|
||
<div class="book-navbar">
|
||
<!-- For Responsive Layout -->
|
||
<header class="navbar">
|
||
<section class="navbar-section">
|
||
<a onclick="open_sidebar()">
|
||
<i class="icon icon-menu"></i>
|
||
</a>
|
||
</section>
|
||
</header>
|
||
</div>
|
||
<div class="book-content" style="max-width: 960px; margin: 0 auto;
|
||
overflow-x: auto;
|
||
overflow-y: hidden;">
|
||
<div class="book-post">
|
||
<p id="tip" align="center"></p>
|
||
<div><h1>10 双刃剑：合理管理 Netty 堆外内存</h1>
|
||
<p>本节课我们将进入 Netty 内存管理的课程学习，在此之前，我们需要了解 Java 堆外内存的基本知识，因为当你在使用 Netty 时，需要时刻与堆外内存打交道。我们经常看到各类堆外内存泄漏的排查案例，堆外内存使用不当会使得应用出错、崩溃的概率变大，所以在使用堆外内存时一定要慎重，本节课我将带你一起认识堆外内存，并探讨如何更好地使用它。</p>
|
||
<h3>为什么需要堆外内存</h3>
|
||
<p>在 Java 中对象都是在堆内分配的，通常我们说的<strong>JVM 内存</strong>也就指的<strong>堆内内存</strong>，<strong>堆内内存</strong>完全被<strong>JVM 虚拟机</strong>所管理，JVM 有自己的垃圾回收算法，对于使用者来说不必关心对象的内存如何回收。</p>
|
||
<p><strong>堆外内存</strong>与堆内内存相对应，对于整个机器内存而言，除<strong>堆内内存以外部分即为堆外内存</strong>，如下图所示。堆外内存不受 JVM 虚拟机管理，直接由操作系统管理。</p>
|
||
<p><img src="assets/CgqCHl-06zuAdxB_AAKnPyI9NhA898.png" alt="图片1.png" /></p>
|
||
<p>堆外内存和堆内内存各有利弊，这里我针对其中重要的几点进行说明。</p>
|
||
<ol>
|
||
<li>堆内内存由 JVM GC 自动回收内存，降低了 Java 用户的使用心智，但是 GC 是需要时间开销成本的，堆外内存由于不受 JVM 管理，所以在一定程度上可以降低 GC 对应用运行时带来的影响。</li>
|
||
<li>堆外内存需要手动释放，这一点跟 C/C++ 很像，稍有不慎就会造成应用程序内存泄漏，当出现内存泄漏问题时排查起来会相对困难。</li>
|
||
<li>当进行网络 I/O 操作、文件读写时，堆内内存都需要转换为堆外内存，然后再与底层设备进行交互，这一点在介绍 writeAndFlush 的工作原理中也有提到，所以直接使用堆外内存可以减少一次内存拷贝。</li>
|
||
<li>堆外内存可以实现进程之间、JVM 多实例之间的数据共享。</li>
|
||
</ol>
|
||
<p>由此可以看出，如果你想实现高效的 I/O 操作、缓存常用的对象、降低 JVM GC 压力，堆外内存是一个非常不错的选择。</p>
|
||
<h3>堆外内存的分配</h3>
|
||
<p>Java 中堆外内存的分配方式有两种：<strong>ByteBuffer#allocateDirect</strong>和<strong>Unsafe#allocateMemory</strong>。</p>
|
||
<p>首先我们介绍下 Java NIO 包中的 ByteBuffer 类的分配方式，使用方式如下：</p>
|
||
<pre><code>// 分配 10M 堆外内存
|
||
ByteBuffer buffer = ByteBuffer.allocateDirect(10 * 1024 * 1024);
|
||
</code></pre>
|
||
<p>跟进 ByteBuffer.allocateDirect 源码，发现其中直接调用的 DirectByteBuffer 构造函数：</p>
|
||
<pre><code>DirectByteBuffer(int cap) {
|
||
super(-1, 0, cap, cap);
|
||
boolean pa = VM.isDirectMemoryPageAligned();
|
||
int ps = Bits.pageSize();
|
||
long size = Math.max(1L, (long)cap + (pa ? ps : 0));
|
||
Bits.reserveMemory(size, cap);
|
||
long base = 0;
|
||
try {
|
||
base = unsafe.allocateMemory(size);
|
||
} catch (OutOfMemoryError x) {
|
||
Bits.unreserveMemory(size, cap);
|
||
throw x;
|
||
}
|
||
unsafe.setMemory(base, size, (byte) 0);
|
||
if (pa && (base % ps != 0)) {
|
||
address = base + ps - (base & (ps - 1));
|
||
} else {
|
||
address = base;
|
||
}
|
||
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
|
||
att = null;
|
||
}
|
||
</code></pre>
|
||
<p>如下图所示，描述了 DirectByteBuffer 的内存引用情况，方便你更好地理解上述源码的初始化过程。在堆内存放的 DirectByteBuffer 对象并不大，仅仅包含堆外内存的地址、大小等属性，同时还会创建对应的 Cleaner 对象，通过 ByteBuffer 分配的堆外内存不需要手动回收，它可以被 JVM 自动回收。当堆内的 DirectByteBuffer 对象被 GC 回收时，Cleaner 就会用于回收对应的堆外内存。</p>
|
||
<p><img src="assets/CgqCHl-060uANzIXAAK8c10kJxc818.png" alt="图片2.png" /></p>
|
||
<p>从 DirectByteBuffer 的构造函数中可以看出，真正分配堆外内存的逻辑还是通过 unsafe.allocateMemory(size)，接下来我们一起认识下 Unsafe 这个神秘的工具类。</p>
|
||
<p>Unsafe 是一个非常不安全的类，它用于执行内存访问、分配、修改等<strong>敏感操作</strong>，可以越过 JVM 限制的枷锁。Unsafe 最初并不是为开发者设计的，使用它时虽然可以获取对底层资源的控制权，但也失去了安全性的保证，所以使用 Unsafe 一定要慎重。Netty 中依赖了 Unsafe 工具类，是因为 Netty 需要与底层 Socket 进行交互，Unsafe 在提升 Netty 的性能方面起到了一定的帮助。</p>
|
||
<p>在 Java 中是不能直接使用 Unsafe 的，但是我们可以通过反射获取 Unsafe 实例，使用方式如下所示。</p>
|
||
<pre><code>private static Unsafe unsafe = null;
|
||
static {
|
||
try {
|
||
Field getUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
|
||
getUnsafe.setAccessible(true);
|
||
unsafe = (Unsafe) getUnsafe.get(null);
|
||
} catch (NoSuchFieldException | IllegalAccessException e) {
|
||
e.printStackTrace();
|
||
}
|
||
}
|
||
</code></pre>
|
||
<p>获得 Unsafe 实例后，我们可以通过 allocateMemory 方法分配堆外内存，allocateMemory 方法返回的是内存地址，使用方法如下所示：</p>
|
||
<pre><code>// 分配 10M 堆外内存
|
||
long address = unsafe.allocateMemory(10 * 1024 * 1024);
|
||
</code></pre>
|
||
<p>与 DirectByteBuffer 不同的是，Unsafe#allocateMemory 所分配的内存必须自己手动释放，否则会造成内存泄漏，这也是 Unsafe 不安全的体现。Unsafe 同样提供了内存释放的操作：</p>
|
||
<pre><code>unsafe.freeMemory(address);
|
||
</code></pre>
|
||
<p>到目前为止，我们了解了堆外内存分配的两种方式，对于 Java 开发者而言，常用的是 ByteBuffer.allocateDirect 分配方式，我们平时常说的堆外内存泄漏都与该分配方式有关，接下来我们一起看看使用 ByteBuffer 分配的堆外内存如何被 JVM 回收，这对我们排查堆外内存泄漏问题有较大的帮助。</p>
|
||
<h3>堆外内存的回收</h3>
|
||
<p>我们试想这么一种场景，因为 DirectByteBuffer 对象有可能长时间存在于堆内内存，所以它很可能晋升到 JVM 的老年代，所以这时候 DirectByteBuffer 对象的回收需要依赖 Old GC 或者 Full GC 才能触发清理。如果长时间没有 Old GC 或者 Full GC 执行，那么堆外内存即使不再使用，也会一直在占用内存不释放，很容易将机器的物理内存耗尽，这是相当危险的。</p>
|
||
<p>那么在使用 DirectByteBuffer 时我们如何避免物理内存被耗尽呢？因为 JVM 并不知道堆外内存是不是已经不足了，所以我们最好通过 JVM 参数 -XX:MaxDirectMemorySize 指定堆外内存的上限大小，当堆外内存的大小超过该阈值时，就会触发一次 Full GC 进行清理回收，如果在 Full GC 之后还是无法满足堆外内存的分配，那么程序将会抛出 OOM 异常。</p>
|
||
<p>此外在 ByteBuffer.allocateDirect 分配的过程中，如果没有足够的空间分配堆外内存，在 Bits.reserveMemory 方法中也会主动调用 System.gc() 强制执行 Full GC，但是在生产环境一般都是设置了 -XX:+DisableExplicitGC，System.gc() 是不起作用的，所以依赖 System.gc() 并不是一个好办法。</p>
|
||
<p>通过前面堆外内存分配方式的介绍，我们知道 DirectByteBuffer 在初始化时会创建一个 Cleaner 对象，它会负责堆外内存的回收工作，那么 Cleaner 是如何与 GC 关联起来的呢？</p>
|
||
<p>Java 对象有四种引用方式：强引用 StrongReference、软引用 SoftReference、弱引用 WeakReference 和虚引用 PhantomReference。其中 PhantomReference 是最不常用的一种引用方式，Cleaner 就属于 PhantomReference 的子类，如以下源码所示，PhantomReference 不能被单独使用，需要与引用队列 ReferenceQueue 联合使用。</p>
|
||
<pre><code>public class Cleaner extends java.lang.ref.PhantomReference<java.lang.Object> {
|
||
private static final java.lang.ref.ReferenceQueue<java.lang.Object> dummyQueue;
|
||
private static sun.misc.Cleaner first;
|
||
private sun.misc.Cleaner next;
|
||
private sun.misc.Cleaner prev;
|
||
private final java.lang.Runnable thunk;
|
||
public void clean() {}
|
||
}
|
||
</code></pre>
|
||
<p>首先我们看下，当初始化堆外内存时，内存中的对象引用情况如下图所示，first 是 Cleaner 类中的静态变量，Cleaner 对象在初始化时会加入 Cleaner 链表中。DirectByteBuffer 对象包含堆外内存的地址、大小以及 Cleaner 对象的引用，ReferenceQueue 用于保存需要回收的 Cleaner 对象。</p>
|
||
<p><img src="assets/Ciqc1F-063GAc4TOAATJbR2Lmao239.png" alt="图片3.png" /></p>
|
||
<p>当发生 GC 时，DirectByteBuffer 对象被回收，内存中的对象引用情况发生了如下变化：</p>
|
||
<p><img src="assets/Ciqc1F-063eAQ7AiAAPPC1-cL1I933.png" alt="图片4.png" /></p>
|
||
<p>此时 Cleaner 对象不再有任何引用关系，在下一次 GC 时，该 Cleaner 对象将被添加到 ReferenceQueue 中，并执行 clean() 方法。clean() 方法主要做两件事情：</p>
|
||
<ol>
|
||
<li>将 Cleaner 对象从 Cleaner 链表中移除；</li>
|
||
<li>调用 unsafe.freeMemory 方法清理堆外内存。</li>
|
||
</ol>
|
||
<p>至此，堆外内存的回收已经介绍完了，下次再排查内存泄漏问题的时候先回顾下这些最基本的知识，做到心中有数。</p>
|
||
<h3>总结</h3>
|
||
<p>堆外内存是一把双刃剑，在网络 I/O、文件读写、分布式缓存等领域使用堆外内存都更加简单、高效，此外使用堆外内存不受 JVM 约束，可以避免 JVM GC 的压力，降低对业务应用的影响。当然天下没有免费的午餐，堆外内存也不能滥用，使用堆外内存你就需要关注内存回收问题，虽然 JVM 在一定程度上帮助我们实现了堆外内存的自动回收，但我们仍然需要培养类似 C/C++ 的分配/回收的意识，出现内存泄漏问题能够知道如何分析和处理。</p>
|
||
</div>
|
||
</div>
|
||
<div>
|
||
<div style="float: left">
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/09 数据传输：writeAndFlush 处理流程剖析.md.html">上一页</a>
|
||
</div>
|
||
<div style="float: right">
|
||
<a href="/专栏/Netty 核心原理剖析与 RPC 实践-完/11 另起炉灶：Netty 数据传输载体 ByteBuf 详解.md.html">下一页</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
|
||
</div>
|
||
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"70997351dbfc3d60","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
|
||
</body>
|
||
<!-- Global site tag (gtag.js) - Google Analytics -->
|
||
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
|
||
<script>
|
||
window.dataLayer = window.dataLayer || [];
|
||
function gtag() {
|
||
dataLayer.push(arguments);
|
||
}
|
||
gtag('js', new Date());
|
||
gtag('config', 'G-NPSEEVD756');
|
||
var path = window.location.pathname
|
||
var cookie = getCookie("lastPath");
|
||
console.log(path)
|
||
if (path.replace("/", "") === "") {
|
||
if (cookie.replace("/", "") !== "") {
|
||
console.log(cookie)
|
||
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
|
||
}
|
||
} else {
|
||
setCookie("lastPath", path)
|
||
}
|
||
function setCookie(cname, cvalue) {
|
||
var d = new Date();
|
||
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
|
||
var expires = "expires=" + d.toGMTString();
|
||
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
|
||
}
|
||
function getCookie(cname) {
|
||
var name = cname + "=";
|
||
var ca = document.cookie.split(';');
|
||
for (var i = 0; i < ca.length; i++) {
|
||
var c = ca[i].trim();
|
||
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
|
||
}
|
||
return "";
|
||
}
|
||
</script>
|
||
</html>
|