Netty：深入解析AbstractByteBufAllocator架构设计

AbstractByteBufAllocator 类结构分析

类结构概览

public abstract class AbstractByteBufAllocator implements ByteBufAllocator {// 静态常量static final int DEFAULT_INITIAL_CAPACITY = 256;static final int DEFAULT_MAX_CAPACITY = Integer.MAX_VALUE;// ...其他常量// 成员变量private final boolean directByDefault;private final ByteBuf emptyBuf;// 抽象方法protected abstract ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity);protected abstract ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity);// 实现方法public ByteBuf buffer() { ... }public ByteBuf heapBuffer() { ... }// ...其他实现方法
}

缓冲区分发逻辑

public ByteBuf buffer(int initialCapacity) {if (directByDefault) {return directBuffer(initialCapacity); // 默认分配直接内存}return heapBuffer(initialCapacity);      // 默认分配堆内存
}
  • ​​智能路由​​：根据 directByDefault 配置自动路由到堆/直接内存分配
  • ​​空缓冲优化​​：对容量0的请求返回共享空对象
if (initialCapacity == 0 && maxCapacity == 0) {return emptyBuf; // 共享空对象减少创建开销
}

组合缓冲区创建

public CompositeByteBuf compositeBuffer() {if (directByDefault) {return compositeDirectBuffer();  // 默认直接内存组合}return compositeHeapBuffer();        // 默认堆内存组合
}protected CompositeByteBuf compositeDirectBuffer(int maxNumComponents) {// 添加泄漏检测包装return toLeakAwareBuffer(new CompositeByteBuf(this, true, maxNumComponents));
}
  • ​​组合类型决策​​：继承默认的内存类型配置
  • ​​泄漏检测集成​​：通过 toLeakAwareBuffer() 添加监控

容量计算算法

public int calculateNewCapacity(int minNewCapacity, int maxCapacity) {final int threshold = 4 * 1024 * 1024; // 4MB阈值if (minNewCapacity > threshold) {// 大对象：按4MB步进扩容int newCapacity = minNewCapacity / threshold * threshold;if (newCapacity > maxCapacity - threshold) {newCapacity = maxCapacity; // 避免溢出} else {newCapacity += threshold;}return newCapacity;}// 小对象：取≥64的最小2的幂次int newCapacity = MathUtil.findNextPositivePowerOfTwo(Math.max(minNewCapacity, 64));return Math.min(newCapacity, maxCapacity);
}
  • ​​双模式扩容​​：
    • ​​小对象​​（<4MB）：2的幂次对齐（64B→128B→256B...）
    • ​​大对象​​（≥4MB）：4MB块对齐（4MB→8MB→12MB...）
  • ​​防溢出保护​​：严格限制 maxCapacity 边界（默认Integer.MAX）

泄漏检测集成

protected static ByteBuf toLeakAwareBuffer(ByteBuf buf) {switch (ResourceLeakDetector.getLevel()) {case SIMPLE:return new SimpleLeakAwareByteBuf(buf, leak);case ADVANCED:case PARANOID:return new AdvancedLeakAwareByteBuf(buf, leak);default:return buf; // DISABLED级别不包装}
}
  • ​​运行时决策​​：根据全局检测级别动态包装
  • ​​透明集成​​：对使用者完全无感知

预留的抽象方法

1. 堆内存分配

protected abstract ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity);

2. 直接内存分配

protected abstract ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity);

​

设计亮点分析

  1. ​​模板方法模式​​
    通过固定分发逻辑（buffer()/directBuffer()） + 抽象创建方法（newXXXBuffer()），实现：

    • 统一入口控制
    • 灵活内存实现
    • 透明泄漏检测

  2. ​​资源优化​​

    • 共享 emptyBuf 减少空对象创建
    • 对象池扩展点（子类可集成PooledByteBufAllocator）

  3. ​​智能扩容​​
    分场景采用不同扩容策略

  4. ​​透明增强​​
    泄漏检测和内存类型决策对调用方不可见：

    // 使用者只需普通调用
ByteBuf buf = allocator.buffer(1024);// 实际获得可能是：
//   SimpleLeakAwareByteBuf → UnpooledHeapByteBuf
//   AdvancedLeakAwareByteBuf → PooledDirectByteBuf

类关系图

​​关键设计意图​​：
通过抽象类实现内存分配的统一路由和公共逻辑，同时保留堆/直接内存实现的扩展性，支持无池化（Unpooled）和对象池化（Pooled）两种内存管理策略。

ResourceLeakDetector 

在 AbstractByteBufAllocator 中，通过 toLeakAwareBuffer() 将 ByteBuf 包装为泄漏检测对象，确保未释放的 ByteBuf 被及时报告。

ResourceLeakDetector 本质是​​资源释放的看门狗​​：

  1. 在对象生命周期内记录关键操作
  2. 通过 GC 回收事件触发最终检查
  3. 对未释放的资源生成溯源报告

ResourceLeakDetector 实现了资源泄漏检测能力​​，用于监控对象（如 ByteBuf）是否在不再使用时被正确释放（如调用 release()）。其核心能力包括：

  1. ​​多级别检测机制​​
    支持 4 种检测级别（通过 Level 枚举控制）：

    • DISABLED：完全禁用检测。
    • SIMPLE：仅报告泄漏存在（低开销）。
    • ADVANCED：记录泄漏对象的访问轨迹（中等开销）。
    • PARANOID：强制跟踪所有对象（高开销，用于测试）。

  2. ​​采样优化​​
    通过 samplingInterval（默认 128）控制跟踪频率，避免全量跟踪的性能损耗：

    • 随机选择部分对象（1/samplingInterval 概率）进行跟踪。
    • PARANOID 级别强制跟踪所有对象。

  3. ​​泄漏轨迹记录​​

    • 记录对象创建点和后续关键操作点（通过 record() 或 record(hint)）。
    • 通过 TraceRecord 链表存储调用栈信息，过滤无关栈帧（如 ResourceLeakDetector 自身方法）。

  4. ​​泄漏报告​​

    • 对象被 GC 后，检查是否未释放 → 生成泄漏报告。
    • 区分两类报告：
      • ​​无轨迹报告​​：仅提示泄漏（SIMPLE 级别）。
      • ​​带轨迹报告​​：显示最近访问记录（ADVANCED/PARANOID 级别）。

  5. ​​动态配置​​
    支持运行时通过系统参数调整：

    -Dio.netty.leakDetection.level=ADVANCED
-Dio.netty.leakDetection.targetRecords=10  // 控制最大记录数

核心设计动机：解决“不可见”的资源泄漏

当看到对象被 GC 回收时，​​真正需要关注的资源可能并未释放​​！典型场景：

  1. ​​堆外内存泄漏​​
    DirectByteBuffer 持有 JVM 堆外内存，GC 会回收 Java 对象本身，但​​关联的堆外内存不会被自动释放​​（需手动调用 cleaner.clean()）。

  2. ​​文件描述符泄漏​​
    文件流对象被 GC 时，底层 OS 文件句柄可能仍未被关闭。

  3. ​​网络连接泄漏​​
    Socket 对象被 GC 不代表 TCP 连接已关闭。

​​ResourceLeakDetector 的核心价值​​：
​​在对象被 GC 前检测资源是否被正确释放​​，避免资源泄漏积累导致系统崩溃。

优势：

1. 解决资源释放的不可见性

  • ​​GC 只回收 Java 堆内存​​，不处理堆外内存/文件句柄等
  • ​​资源释放依赖手动调用​​（如 release()/close()）

2. 定位泄漏点的困难性

  • 传统内存分析工具（如 MAT）无法追踪：
    • 何时忘记调用释放？
    • 在哪里最后一次使用资源？
  • 通过 record() 记录业务操作点，精准定位泄漏位置

3. 性能与效果的平衡

  • ​​弱引用 + 采样机制​​：对 GC 影响极小
  • ​​轨迹压缩算法​​：仅保留关键操作链（见 TARGET_RECORDS）

追踪过程解析（关键生命周期）

阶段 1：资源使用中（对象存活期）

// 创建需手动释放的资源
ByteBuf buf = allocator.directBuffer(1024);// 绑定泄漏追踪器
ResourceLeakTracker<ByteBuf> leakTracker = leakDetector.track(buf);// 使用资源（记录关键操作点）
leakTracker.record("解析HTTP头部");
buf.writeBytes(...);

阶段 2：资源应释放时（人为失误）

// 忘记调用释放!
// buf.release(); // 此时：Java 对象仍在，但业务已不再使用它

阶段 3：GC 回收对象（最后的检测机会）

// 当 buf 对象被 GC 回收时：
// 1. 弱引用 leakTracker 进入 ReferenceQueue
// 2. ResourceLeakDetector 轮询队列发现：
//    - leakTracker 未被 close() → 标记为泄漏
//    - 生成泄漏报告（含阶段1的记录点）

阶段 4：泄漏报告（亡羊补牢）

LEAK: ByteBuf.release() 未调用
最近访问记录:
#1:Hint: 解析HTTP头部at com.example.HttpHandler.channelRead(...)
#2:at com.example.MessageDecoder.decode(...)

对象关系图解

  1. ​​Resource​​
    需手动释放的资源对象（如 ByteBuf）

  2. ​​ResourceLeakTracker​​

    • 持有资源的​​弱引用​​（不影响 GC）
    • 记录资源操作轨迹
    • 需显式调用 close() 标记已释放

  3. ​​GC 机制​​
    资源对象被回收时，弱引用自动入队

  4. ​​ResourceLeakDetector​​
    轮询队列，检测未关闭的 tracker

关键实现分析

​​泄漏跟踪入口（track()）​​

public ResourceLeakTracker<T> track(T obj) {return track0(obj, false);
}private DefaultResourceLeak track0(T obj, boolean force) {Level level = getLevel();if (force || level == Level.PARANOID || (level != Level.DISABLED && random.nextInt(samplingInterval) == 0)) {reportLeak(); // 清理队列并报告已有泄漏return new DefaultResourceLeak(obj, refQueue, allLeaks, initialHint);}return null; // 不跟踪
}
  • ​​采样逻辑​​：非 PARANOID 时，按 1/samplingInterval 概率跟踪对象。
  • ​​前置清理​​：先处理引用队列中的待报告泄漏。

泄漏记录（DefaultResourceLeak.record()）​​

private void record0(Object hint) {TraceRecord newHead = new TraceRecord(oldHead, hint); // 创建新记录节点while (!headUpdater.compareAndSet(this, oldHead, newHead)) {// CAS 更新链表头}// 超过 TARGET_RECORDS 时按指数退避随机丢弃旧记录if (numElements >= TARGET_RECORDS) {int backOffFactor = Math.min(numElements - TARGET_RECORDS, 30);if (ThreadLocalRandom.current().nextInt(1 << backOffFactor) != 0) {prevHead = oldHead.next; // 丢弃最旧记录}}
}
  • ​​记录链结构​​：TraceRecord 链表存储历史记录，新记录插入头部。
  • ​​淘汰策略​​：超过 TARGET_RECORDS 时，按 1/(2^N) 概率丢弃旧记录（N=超限次数），优先保留新记录。

​​泄漏检测（reportLeak()）​​

private void reportLeak() {while ((ref = (DefaultResourceLeak) refQueue.poll()) != null) {if (!ref.dispose()) continue; // 检查是否已释放String records = ref.getReportAndClearRecords();if (reportedLeaks.add(records)) { // 避免重复报告if (records.isEmpty()) {reportUntracedLeak(resourceType); // 无轨迹报告} else {reportTracedLeak(resourceType, records); // 带轨迹报告}}}
}
  • ​​引用队列机制​​：通过 WeakReference + ReferenceQueue 感知对象 GC。
  • ​​泄漏判定​​：对象被 GC 时，若未调用 close() → 标记为泄漏。

轨迹报告生成（getReportAndClearRecords()）​​

String generateReport(TraceRecord oldHead) {StringBuilder buf = new StringBuilder();Set<String> seen = new HashSet<>();for (; oldHead != BOTTOM; oldHead = oldHead.next) {String trace = oldHead.toString(); // 格式化调用栈if (seen.add(trace)) { // 去重buf.append("#").append(i++).append(":").append(trace);}}// 添加丢弃记录统计if (droppedRecords > 0) {buf.append(": ").append(droppedRecords).append(" records discarded");}return buf.toString();
}
  • ​​栈帧过滤​​：排除 excludedMethods 中的无关方法（如 Netty 内部方法）。
  • ​​去重机制​​：合并重复调用栈。

关键设计亮点

  1. ​​开销控制​​

    • 采样率 + 记录淘汰策略 → 平衡检测精度与性能。
    • DISABLED/SIMPLE 级别几乎无性能影响。

  2. ​​轨迹优化​​

    • 指数退避淘汰策略优先保留新记录，更易定位泄漏点。
    • 过滤内部栈帧 → 报告更简洁。

  3. ​​线程安全​​

    • ConcurrentHashMap（allLeaks）+ AtomicReferenceFieldUpdater（链表头）→ 无锁并发。

  4. ​​扩展性​​

    • 支持自定义 LeakListener 监听泄漏事件。
    • 可通过 ResourceLeakDetectorFactory 定制实现。

UnpooledByteBufAllocator 

类结构全景

public class UnpooledByteBufAllocator extends AbstractByteBufAllocator {// 内存分配决策标志private final boolean disableLeakDetector;// 单例实例（Netty核心优化）public static final UnpooledByteBufAllocator DEFAULT = new UnpooledByteBufAllocator(false);// 构造器public UnpooledByteBufAllocator(boolean preferDirect) { ... }public UnpooledByteBufAllocator(boolean preferDirect, boolean disableLeakDetector) { ... }// 核心实现方法protected ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity) { ... }protected ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity) { ... }// 特有方法public boolean isDirectBufferPooled() { ... }
}

堆内存分配（newHeapBuffer）

protected ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity) {return new UnpooledHeapByteBuf(this, initialCapacity, maxCapacity);
}
  • ​​直接创建​​：实例化 UnpooledHeapByteBuf 不经过对象池
  • ​​堆内存管理​​：内部维护 byte[] 数组，完全依赖 JVM GC

直接内存分配（newDirectBuffer）

protected ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity) {ByteBuf buf;if (PlatformDependent.hasUnsafe()) {// 优先使用Unsafe加速操作buf = new UnpooledUnsafeDirectByteBuf(this, initialCapacity, maxCapacity);} else {// 回退到标准NIO实现buf = new UnpooledDirectByteBuf(this, initialCapacity, maxCapacity);}return disableLeakDetector ? buf : toLeakAwareBuffer(buf);
}
  • ​​运行时决策​​：根据平台能力选择最佳实现
  • ​​泄漏检测控制​​：通过 disableLeakDetector 开关

平台适配优化

public boolean isDirectBufferPooled() {// 直接内存是否由JVM管理return false; 
}public ByteBuf ioBuffer(int initialCapacity) {if (PlatformDependent.hasUnsafe() || isDirectBufferPooled()) {// 优先直接内存return directBuffer(initialCapacity); }return heapBuffer(initialCapacity); // 回退堆内存
}
  • ​​智能路由​​：自动选择最佳 I/O 缓冲区类型
  • ​​JVM 适配​​：兼容非Unsafe环境（如 Android）

内存释放机制

// UnpooledDirectByteBuf 释放实现
protected void deallocate() {freeArray(array);array = EmptyArrays.EMPTY_BYTES;
}// 直接内存释放（UnpooledUnsafeDirectByteBuf）
protected void deallocate() {ByteBuffer buffer = this.buffer;if (buffer == null) return;PlatformDependent.freeDirectBuffer(buffer);this.buffer = null;
}
  • ​​显式释放​​：直接内存立即调用 freeDirectBuffer()
  • ​​防御性编程​​：多次释放安全（null 检查）

统计监控

​内存统计​​：

// 基于LongAdder的无锁计数
final LongAdder directCounter = new LongAdder(); 
void incrementDirect(int amount) {directCounter.add(amount);
}
  • 实时监控堆/直接内存使用量
  • 统计精度达字节级（metric().usedDirectMemory()）

​​泄漏检测​​：

return disableLeakDetector ? buf : toLeakAwareBuffer(buf);
  • 通过 ResourceLeakDetector 追踪未释放缓冲区
  • 可配置阈值（默认采样检测，避免性能损耗）

设计分析

  1. ​​泄漏检测精细控制​​

    • 通过构造器参数 disableLeakDetector 完全关闭检测
    • 适用于性能敏感场景（如高频临时缓冲区）

  2. ​​零内存复用设计​​

    • 与 PooledByteBufAllocator 核心区别：
      特性UnpooledPooled
      分配速度快中
      内存碎片高低
      GC压力高低
      适合场景短期对象长期持有

  3. ​​全局单例优化​​

    public static final UnpooledByteBufAllocator DEFAULT = new UnpooledByteBufAllocator(false);
    • 避免重复创建分配器实例
    • 通过 preferDirect 控制默认内存类型

典型使用场景

  1. ​​协议解析​​：短期存在的请求/响应缓冲区

    // HTTP请求解析
ByteBuf requestBuffer = UnpooledByteBufAllocator.DEFAULT.buffer();
channel.read(requestBuffer);

  2. ​​测试环境​​：避免对象池干扰测试结果

    @Test
void testDecoder() {ByteBufAllocator alloc = new UnpooledByteBufAllocator(true);// 测试逻辑...
}

  3. ​​Android 平台​​：规避 Unsafe 限制

    // 自动回退到堆内存
ByteBuf buf = allocator.ioBuffer(1024);

​

在 Netty 4.1+ 中，默认使用 PooledByteBufAllocator，但可通过启动参数切换：

-Dio.netty.allocator.type=unpooled

UnpooledByteBufAllocator 完美诠释了 "Simple is Best" 的设计哲学，在特定场景下仍是不可或缺的选择。

UnpooledUnsafeDirectByteBuf vs UnpooledDirectByteBuf 

UnpooledUnsafeDirectByteBuf 是 UnpooledDirectByteBuf 的子类，主要区别在于：

  • UnpooledDirectByteBuf: 使用标准的 NIO ByteBuffer API 进行内存操作
  • UnpooledUnsafeDirectByteBuf: 使用 sun.misc.Unsafe 直接进行内存地址操作

"Unsafe" 体现在哪里

直接内存地址操作

// UnpooledUnsafeDirectByteBuf 中的关键字段
long memoryAddress;  // 直接存储内存地址// 获取内存地址的方法
final long addr(int index) {return memoryAddress + index;  // 直接计算内存地址
}

底层内存访问方式

UnpooledUnsafeDirectByteBuf 通过 UnsafeByteBufUtil 类使用 sun.misc.Unsafe 进行操作：

// 读取操作示例
@Override
protected byte _getByte(int index) {return UnsafeByteBufUtil.getByte(addr(index));  // 直接内存访问
}@Override
protected int _getInt(int index) {return UnsafeByteBufUtil.getInt(addr(index));   // 直接内存访问
}final class UnsafeByteBufUtil {static byte getByte(long address) {return PlatformDependent.getByte(address);}

而 UnpooledDirectByteBuf 则使用标准 NIO ByteBuffer：

// UnpooledDirectByteBuf 中的典型操作
buffer.get(index);    // 通过 ByteBuffer API
buffer.getInt(index); // 通过 ByteBuffer API

性能优势

减少边界检查

  • Unsafe 方式直接操作内存地址，跳过了 ByteBuffer 的边界检查
  • 在高频读写场景下性能更优

更高效的内存操作

// 批量操作示例
@Override
public ByteBuf setZero(int index, int length) {checkIndex(index, length);UnsafeByteBufUtil.setZero(addr(index), length);  // 直接内存清零return this;
}

从代码可以看出，只有在满足特定条件时才使用 Unsafe 版本：

// 在 Unpooled.wrappedBuffer() 中的逻辑
if (PlatformDependent.hasUnsafe()) {// 使用 Unsafe 版本return new UnpooledUnsafeDirectByteBuf(ALLOC, buffer, buffer.remaining());
} else {// 降级使用标准版本return new UnpooledDirectByteBuf(ALLOC, buffer, buffer.remaining());
}

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/diannao/88559.shtml
繁体地址，请注明出处：http://hk.pswp.cn/diannao/88559.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Java 日志管理与分析

Java 日志管理与分析

为什么需要日志 ■ 发⽣了什么&#xff08;What&#xff09;。 ■ 何时发⽣的&#xff08;When&#xff09;。 ■ 发⽣于何处&#xff08;Where&#xff09;。 ■ 谁参与其中&#xff08;Who&#xff09;。 ■ 参与者来源&#xff08;第⼆个Where&#xff0c;注意与上⾯的Wher…
阅读更多...
bmc TrueSight 监控mysql配置

bmc TrueSight 监控mysql配置

bmc TrueSight 监控mysql配置 1.将pat加入mysql组 useradd pat;echo patpassword|passwd --stdin pat usermod -aG mysql pat2.设置环境变量 查看文件是否存在[rootu1acmsdp01 ~]# find / -name mysql.sock /var/lib/mysql/mysql.sock ^C [rootu1acmsdp01 ~]# cd /var/lib/my…
阅读更多...
WinAppDriver 自动化测试：C#篇

WinAppDriver 自动化测试：C#篇

💖亲爱的技术爱好者们，热烈欢迎来到 Kant2048 的博客！我是 Thomas Kant，很开心能在CSDN上与你们相遇～💖 本博客的精华专栏： 【自动化测试】 【测试经验】 【人工智能】 【Python】
阅读更多...
zlmediakit webrtc搭建使用

zlmediakit webrtc搭建使用

webrtc 编译与使用 | ZLMediaKit 官方文档参考 编译机器&#xff1a; centos 7.6 gcc 版本 10.1.0 (GCC) cmake version 3.23.0web播放rtsp流视频&#xff0c;使用webrtc毫秒级延迟_webrtc播放rtsp流-CSDN博客 依赖准备 openssl 安装 (openssl 版本要求 1.1 以上) 我的…
阅读更多...
Linux下使用docker nginx部署vue前端项目工程

Linux下使用docker nginx部署vue前端项目工程

1、使用Docker和Nginx部署Vue项目的步骤 1、准备好VUE项目&#xff0c;已打包编译 2、docker环境已完成安装 3、本地环境上创建nginx目录&#xff0c;下包括conf&#xff0c;html&#xff0c;logs目录。用于容器映射&#xff08;其实是方便修改文件&#xff0c;因为在容器中…
阅读更多...
从实验室到生产线：机器学习模型部署的七大陷阱及PyTorch Serving避坑指南

从实验室到生产线：机器学习模型部署的七大陷阱及PyTorch Serving避坑指南

1 实验室与生产环境的鸿沟&#xff1a;为什么99%的模型部署会失败&#xff1f; &#xff08;1&#xff09;部署失败的真实数据统计 根据2023年MLOps行业报告&#xff1a; 78%的组织表示模型部署时间超过预期65%的模型部署后性能下降超过20%仅12%的组织能在一周内完成模型更新…
阅读更多...
Module not found: Error: Can‘t resolve ‘core-js/modules/es.array.concat.js‘

Module not found: Error: Can‘t resolve ‘core-js/modules/es.array.concat.js‘

遇到错误“Module not found: Error: Can’t resolve ‘core-js/modules/es.array.concat.js’”通常是因为你的项目中使用了core-js库&#xff0c;但是你的项目配置或者core-js的版本不支持你正在尝试使用的功能。下面是一些解决这个问题的步骤&#xff1a; 确认core-js版本 …
阅读更多...
Windows10中设置多个虚拟IP方法

Windows10中设置多个虚拟IP方法

一.netsh 命令添加&#xff08;最直接、最简单&#xff09; 1.在 Windows 10 中&#xff0c;使用 netsh 命令为现有物理网卡或虚拟网卡添加额外的 IP 地址&#xff08;IP Alias&#xff09;是最直接的方法。这些 IP 地址与主 IP 在同一网段&#xff0c;共享同一张网卡的 MAC 地…
阅读更多...
回答 如何通过inode client的SSLVPN登录之后，访问需要通过域名才能打开的服务

回答 如何通过inode client的SSLVPN登录之后，访问需要通过域名才能打开的服务

需要dns代理 1 配置需求或说明 1.1 适用的产品系列 本案例适用于软件平台为Comware V7系列防火墙&#xff1a;本案例适用于如F5080、F5060、F5030、F5000-M等F5000、F5000-X系列的防火墙。 注&#xff1a;本案例是在F100-C-G2的Version 7.1.064, Release 9510P08版本上进行…
阅读更多...
Jenkins通过Pipeline流水线方式编译前端项目

Jenkins通过Pipeline流水线方式编译前端项目

本文记录了本人在前端项目持续集成与自动化部署方面的实践经验&#xff0c;使用 Jenkins 官方 jenkins:lts 镜像为基础&#xff0c;构建支持 Node.js 构建和压缩能力的运行环境&#xff0c;并通过声明式 Pipeline 实现一套多环境&#xff08;SIT/PROD&#xff09;可选的一键部署…
阅读更多...
Dockerfile 镜像构建

Dockerfile 镜像构建

目录 简介 一、Docker镜像概念与结构 1.1 镜像的分层存储机制 1.2 镜像分层的关键特性 二、Dockerfile语法 2.1 基础构建指令 2.2 环境配置指令 2.3 文件操作指令 2.4 运行时指令 2.5 网络与数据管理 三、实战案例 3.1 构建Nginx Web服务器 3.2 构建Tomcat应用服务…
阅读更多...
Docker Desktop 4.42集成的MCP工具包

Docker Desktop 4.42集成的MCP工具包

一、介绍 Docker Desktop 4.42 集成了 MCP&#xff08;Model‑Client‑Plugin&#xff09;Toolkit&#xff0c;无需额外安装扩展即可直接使用。 MCP Toolkit 集成细节 内置于 Docker Desktop&#xff1a;你可以直接打开应用&#xff0c;在设置中启用 MCP 服务器&#xff0c;比…
阅读更多...
CUDA NCU Occupancy学习笔记

CUDA NCU Occupancy学习笔记

占用率是每个多处理器的活跃 Warp 数量与最大可能活跃 Warp 数量的比率。另一种查看占用率的方式是&#xff0c;硬件处理 Warp 的能力中&#xff0c;实际使用 Warp 的百分比。较高的占用率并不一定能带来更高的性能&#xff0c;然而&#xff0c;较低的占用率总是会降低隐藏延迟…
阅读更多...
配置自己的NTP 服务器做时间同步

配置自己的NTP 服务器做时间同步

✅ 推荐方案&#xff1a;使用 chrony 搭建 NTP 服务器&#xff08;适用于 CentOS 7/8/9&#xff09; chrony 是 CentOS 推荐的 NTP 实现&#xff0c;精度高、资源占用低、同步快&#xff0c;默认在 CentOS 8 中取代了 ntpd。 &#x1f527; 一、安装 chrony sudo yum install…
阅读更多...
【运维系列】Plane 开源项目安装和配置指南

【运维系列】Plane 开源项目安装和配置指南

Plane是一个用现代前端技术栈&#xff08;Next.js TailwindCSS&#xff09;开发的开源项目管理平台&#xff0c;核心理念是 Bring Structure to Chaos" —— 给混乱的项目管理带来结构感。 1.项目地址 gitHub 2.项目使用的关键技术和框架 Plane 项目使用了多种关键技术…
阅读更多...
3.读取图片和图片采集

3.读取图片和图片采集

目录 一、Halcon 1. 图片的基本概念 2. 获取图片方式1-读取本地图片 3. 获取图片方式2-在线采集 4. C#获取图片数据架构 二、VS联合编程 1. 读取本地图片 2.在线采集 一、Halcon 1. 图片的基本概念 1. 图片2. 像素 3. 分辨率4. 位深度5. 不同后缀1. png jpg 2. bmp 6…
阅读更多...
前端流式接口/Socket.IO/WebSocket的区别和选用

前端流式接口/Socket.IO/WebSocket的区别和选用

WebSocket&#xff1a; 定义&#xff1a;WebSocket是一种在单个TCP连接上进行全双工通信的协议&#xff0c;实现了客户端与服务器之间的实时双向通信。特点&#xff1a;基于HTTP协议&#xff0c;但通过握手升级为WebSocket协议&#xff0c;支持持久连接&#xff0c;减少延迟和带…
阅读更多...
QT 学习笔记摘要(二)

QT 学习笔记摘要(二)

第一节 常用控件 1. QWidget 核心属性 1.1 objectName 1.2 enabled API说明 isEnabled() 获取到控件的可⽤状态 setEnabled() 设置控件是否可使⽤. true 表⽰可⽤, false 表⽰禁⽤ 1.3 geometry && window frame geometry: x y width height API 说明 geom…
阅读更多...
FastAPI + Redis 高性能任务队列实现：AI内容生成系统实践

FastAPI + Redis 高性能任务队列实现：AI内容生成系统实践

FastAPI Redis 高性能任务队列实现&#xff1a;AI内容生成系统实践 引言 在现代应用中&#xff0c;任务队列是处理资源密集型操作的重要组件。本文将详细介绍一个基于FastAPI和Redis实现的高性能任务队列系统&#xff0c;该系统用于处理AI图片和视频的生成请求。我们将从架构…
阅读更多...
光学跟踪系统在汽车远程设计验证中的应用优势

光学跟踪系统在汽车远程设计验证中的应用优势

在汽车制造行业&#xff0c;传统设计验证流程依赖实体模型评审&#xff0c;存在周期长、成本高、跨地域协作困难等痛点。随着光学跟踪技术的突破&#xff0c;以ART、OptiTrack为代表的高精度光学追踪系统正重塑汽车远程设计验证的范式。本文从技术原理、应用场景及产业价值三个…
阅读更多...
最新文章

Copyright @ 2022~2023