小菜鸟

java菜鸟号正在起航

0%

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 4.2k 阅读时长 ≈ 4 分钟

Netty 缓冲区 ByteBuf 详解：设计与使用指南

Netty 的 ByteBuf 是对 JDK 原生 ByteBuffer 的增强，解决了其固定容量、读写指针切换繁琐等问题，是 Netty 网络数据传输的核心容器。本文将深入解析 ByteBuf 的设计理念、核心特性及使用模式，帮助理解其如何提升网络编程效率。

ByteBuf 与 ByteBuffer 的核心差异

JDK 原生 ByteBuffer 在高并发网络编程中存在明显局限，而 ByteBuf 通过针对性设计解决了这些问题：

特性 JDK ByteBuffer Netty ByteBuf
容量灵活性 固定容量，创建后不可修改 动态扩容，支持自动调整容量（≤ maxCapacity）
读写指针 单指针 position，需手动 flip() 切换读写模式 双指针 readerIndex（读）和 writerIndex（写），无需切换
内存管理 仅堆内存（HeapByteBuffer） 支持堆内存、直接内存（堆外）及复合缓冲区
操作便捷性 方法繁琐（如 get()/put() 需手动控制指针） 提供丰富的读写方法（如 readInt()/writeInt()），自动更新指针

动态扩容机制

ByteBuf 允许在写入数据时自动扩容（默认最大容量为 Integer.MAX_VALUE），扩容策略为：

  • 当容量 < 4MB 时，每次翻倍扩容（如 64B → 128B → 256B…）。
  • 当容量 ≥ 4MB 时，每次增加 4MB。
阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 4.2k 阅读时长 ≈ 4 分钟

分布式锁详解：实现方案与对比分析

在分布式系统中，多个节点竞争同一资源（如库存扣减、订单创建）时，需通过分布式锁保证操作的原子性，避免数据不一致。常见实现方式包括 Redis、ZooKeeper 和数据库，每种方案各有优劣，需根据场景选择。以下详细解析各方案的原理、代码实现及适用场景。

Redis 分布式锁：高性能的选择

Redis 凭借其高性能和原子操作特性，成为分布式锁的主流实现方案。核心思路是通过 set 命令的原子性实现加锁，结合过期时间和唯一标识避免死锁。

基础实现（setnx + expire 的问题与优化）

  • 原始方案：使用 setnx 加锁（仅当 key 不存在时成功），expire 设置过期时间（避免死锁）。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    // 加锁：若 key 不存在则设置，返回 1 表示成功
    Long setnx = jedis.setnx("lock:order", "1");
    if (setnx == 1) {
        // 设置过期时间（30 秒）
        jedis.expire("lock:order", 30);
        // 执行业务逻辑
        // ...
        // 释放锁
        jedis.del("lock:order");
    }

    问题：setnx 和 expire 是非原子操作，若加锁后未设置过期时间就宕机，会导致锁永久有效。

  • 优化方案：使用 Redis 2.6.12+ 支持的 set 命令扩展参数，实现 “加锁 + 过期时间” 原子操作：

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 1.6k 阅读时长 ≈ 1 分钟

TCP 连接参数优化详解：聚焦 TIME_WAIT 与端口管理

下面详细解析每个参数的作用、配置逻辑及注意事项。

核心参数解析与配置建议

参数 作用 风险与注意事项 推荐配置
net.ipv4.tcp_max_tw_buckets 限制系统中 TIME_WAIT 状态的最大连接数，超过则强制清除 数值过低可能导致正常连接被误删；过高会占用大量端口资源 10000-50000（根据并发量调整，建议不低于 10000）
net.ipv4.ip_local_port_range 定义客户端发起连接时可用的端口范围 范围过小可能导致高并发下 “端口耗尽”；需避免与知名端口（1-1023）冲突 1024 65000（扩大可用端口池，覆盖非特权端口）
net.ipv4.tcp_tw_reuse 允许将 TIME_WAIT 状态的端口复用为新连接 仅对客户端主动发起的连接有效；需配合 tcp_timestamps 开启 1（开启，显著减少 TIME_WAIT 占用）
net.ipv4.tcp_tw_recycle 加速 TIME_WAIT 状态的端口回收（已逐步被内核移除） 在 NAT 网络（如云服务器、局域网）中会导致连接失败（时间戳校验冲突） 不推荐开启（设为 0，新内核已废弃该参数）
net.ipv4.tcp_syncookies 当 SYN 队列溢出时，用 Cookie 验证连接合法性，防御 SYN 洪水攻击 开启会轻微增加 CPU 消耗；极端高并发下可能影响连接建立效率 1（默认开启，平衡安全性与可用性）

参数协同逻辑

这些参数需配合使用才能发挥最大效果，核心逻辑如下：

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 12k 阅读时长 ≈ 11 分钟

Spring AOP 注解开启全流程源码解析：从 <aop:aspectj-autoproxy/> 到代理生成

Spring AOP 注解功能（如 @Aspect、@Before）的开启依赖 <aop:aspectj-autoproxy/> 配置，其底层是一套 “自定义标签解析→核心处理器注册→BeanPostProcessor 介入→AOP 代理生成” 的完整链路。从 “自定义标签解析”“核心处理器初始化”“BeanPostProcessor 调用时机”“AOP 代理生成” 四个维度，逐行拆解 AOP 注解开启的底层逻辑。

前置知识：Spring 自定义标签解析机制

<aop:aspectj-autoproxy/> 并非 Spring 内置的 “默认标签”（如 <bean>、<import>），而是自定义标签。Spring 解析自定义标签需依赖两个核心配置文件和一套解析流程：

自定义标签的核心配置文件

Spring 通过类路径下的 META-INF/spring.handlers 和 META-INF/spring.schemas 关联自定义标签与解析逻辑：

  • spring.handlers：映射 “命名空间（namespace）” 到 “标签处理器（NamespaceHandler）”，告诉 Spring 用哪个类解析该命名空间下的标签；
  • spring.schemas：映射 “XSD Schema 地址” 到 “本地 XSD 文件”，用于校验自定义标签的语法合法性。
示例：AOP 自定义标签的配置
1
2
3
4
5
# spring.handlers：aop 命名空间对应 AopNamespaceHandler
http\://www.springframework.org/schema/aop=org.springframework.aop.config.AopNamespaceHandler

# spring.schemas：aop XSD 地址对应本地文件（避免联网下载）
http\://www.springframework.org/schema/aop/spring-aop-3.1.xsd=org/springframework/aop/config/spring-aop-3.1.xsd

自定义标签的解析流程

当 Spring 解析 XML 配置遇到自定义标签（如 <aop:aspectj-autoproxy/>）时，执行以下步骤：

  1. 提取命名空间：从标签的 xmlns:aop 属性获取命名空间（http://www.springframework.org/schema/aop）；
  2. 获取处理器：通过 NamespaceHandlerResolver 从 spring.handlers 中找到对应的 AopNamespaceHandler；
  3. 初始化处理器：调用 AopNamespaceHandler.init() 注册标签解析器；
  4. 解析标签：根据标签名称（aspectj-autoproxy）调用对应的解析器（AspectJAutoProxyBeanDefinitionParser）。
阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 2.5k 阅读时长 ≈ 2 分钟

消息重复消费问题：原因分析与解决方案

消息重复消费是分布式消息系统中常见的问题，指同一消息被消费者多次处理，可能导致业务数据不一致（如重复下单、重复扣款）。本文深入分析重复消费的根源，并提供可落地的解决方案，确保消息处理的幂等性。

消息重复消费的根本原因

消息重复的本质是 “消息传递状态不明确”：发送方或中间件无法确定消息是否已被正确处理，从而触发重试机制。具体可分为两类场景：生产者重复发送和中间件重复投递 。

生产者重复发送消息

生产者（消息发送方）因 “不确定消息是否已被中间件接收” 而重复发送，常见原因：

场景 具体描述
中间件响应超时 生产者发送消息后，中间件已成功存储但响应缓慢，生产者触发超时重试，导致重复发送。
网络波动 消息已到达中间件，但返回的 “发送成功” 响应在网络传输中丢失，生产者误认为发送失败并重试。
中间件故障 中间件处理消息时崩溃，重启后未记录已接收的消息，生产者重试时再次发送。

示例：订单系统发送 “创建订单” 消息，中间件存储成功但返回响应时宕机，订单系统未收到确认，5 秒后重试发送，导致中间件收到两条相同消息。

消息中间件重复投递

中间件（如 RabbitMQ、Kafka）因 “不确定消费者是否已处理消息” 而重复投递，常见原因：

阅读全文 »