Java on FelixHao's Blog

在Java中如何正确的使用Kafka

Sat, 20 Dec 2025 15:16:48 +0800

前言

在系统中引入消息中间件不可避免的需要处理如下的几个问题:

如何保证消息不丢失?
如果解决消息重复消费的问题?
如何保证消息的顺序消费?
消息消费失败了怎么办??

文章就上述几个问题，通过 Java + Kafka 来解释

Kafka 的三种消息投递语义

语义	含义	说明	实现方式
At most once	最多一次	有丢失消息的风险	生产者投递失败后不重试
At least once	至少一次	会导致消息重复	- 生产者投递失败后进行重试 - 消费者手动提交 ACK
Exactly once	只有一次	消息不丢失，消息不重复	Kafka 事务

kafka 处于哪种消息语义取决于生产者配置的 acks 参数，不同 acks 配置的含义:

acks=0: 生产者发送消息后，完全不等待 Broker 的确认，立即发送下一条消息。吞吐量高，但消息可能在 Broker 接收到之前丢失或者 Broker 只写入了 Leader Partition，将消息写入 Follower Partition 的时候 Leader Partition 所在的 Broker 挂掉，导致消息丢失。
acks=1: 消息只要写入 Leader Partition 就立即发送 ACK。如果 Broker 在将消息写入 Follower Partition 之前挂掉了，会导致消息丢失。
acks=all 或者 acks=-1: 消息成功写入到 Leader Partition 以及所有的 Follower Partition 之后，Broker 才会给 Producer 发送 ACK。这种情况下不会导致消息的丢失。

根据上述 acks 参数的配置:

acks=0 表示 At most once 语义
acks=1 或 acks=all 表示的是 At least once 语义

spring-kafka 包中，acks 的默认值是 acks=1。

如何保证消息不丢失?

消息的流转过程: Producer -> Broker -> Consumer

上述环节中的任意一个环节都有可能造成消息的丢失:

在 Producer 和 Broker 之间，为了防止消息丢失，需要引入 ACK 确认机制
在 Broker 和 Consumer 之间，为了防止消息丢失，需要关闭自动提交 offet 的功能，改成手动提交 offset
Broker 配置不当也可能导致消息的丢失，需要合理的配置: replication.factor 和 min.insync.replicas 参数。
- replication.factor 参数表示每个 partition 有多少副本
- min.insync.replicas 参数表示集群中每个 partition 至少需要多少副本与 Leader 副本保持同步，集群才可以正常运行。如果处于同步状态的副本数低于 min.insync.replicas 参数，将消息发送到 Broker 时，会被拒绝写入。

看下在 Spring Boot 项目中如何配置 application.yaml 文件:

spring:
  kafka:
    consumer:
      enable-auto-commit: false # 关闭自动提交 Offset
      auto-offset-reset: earliest # 找不到 partition 的历史消费 offset 时，将 offset 重置到 partition 最早的位置开始消费
    listener:
      ack-mode: manual_immediate # 消费完毕后立即提交 ack
    producer:
      acks: all # Leader 和 Follower Partition 都成功写入后 Broker 再发送 ack
      properties:
        enable.idempotence: true # 开启幂等性，确保每个消息只会被存储一次。通过 producer id + sequence id 保证
        max.in.flight.requests.per.connection: 5 # 最多允许多少条消息等待 broker 的 ACK。设置成 1 表示消息顺序发送。
        retries: 2147483647 # 重试次数
        request.timeout.ms: 30000 # 发送请求后等待 Broker 响应的超时时间
        delivery.timeout.ms: 120000 # 消息从准备到最终被 Broker 接收并返回 ACK 确认的超时时间，其中包括了 request.timeout.ms
        linger.ms: 5 # 每个 batch(批次) 收集消息的时间，单位 ms。设置成 0 表示有消息立即发送。大于 0 表示每隔 n 毫秒发送一次消息。

如何解决消息重复消费?

什么情况下会导致重复消费?

Producer 将同一条消息多次发送给 Broker，导致 Broker 中存在多条相同的消息
Broker 将同一条消息多次发送给 Consumer

生产端和消费端都有可能导致消息重复消费，接下来看看如何解决

生产端

生产端导致重复消费的问题，可以让 Producer 开启幂等模式。开启幂等模式后，Producer 发送的消息会携带 Producer Id(PID) 以及自增的序列号，Broker 会根据 PID 以及序列号判断消息在 Broker 中是否存在，如果存在直接返回 ACK，如果不存在，则将消息成功写入 Broker 后，再发送 ACK。

spring:
  kafka:
    producer:
      acks: all # Leader 和 Follower Partition 都成功写入后 Broker 再发送 ack
      properties:
        enable.idempotence: true # 开启幂等性，确保每个消息只会被存储一次。通过 producer id + sequence id 保证
        max.in.flight.requests.per.connection: 5 # 最多允许多少条消息等待 broker 的 ACK。设置成 1 表示消息顺序发送。
        retries: 2147483647 # 重试次数
        request.timeout.ms: 30000 # 发送请求后等待 Broker 响应的超时时间
        delivery.timeout.ms: 120000 # 消息从准备到最终被 Broker 接收并返回 ACK 确认的超时时间，其中包括了 request.timeout.ms
        linger.ms: 5 # 每个 batch(批次) 收集消息的时间，单位 ms。设置成 0 表示有消息立即发送。大于 0 表示每隔 n 毫秒发送一次消息。

这种方式有个问题: 幂等只在 Producer 和 Broker 的同一次会话中有效。Producer ID 是每次建立会话时 Broker 随机分配的，Broker 不会验证消息的内容，只会根据 Producer ID + 序列号 判断消息是否重复。而 Producer 重启后，会被重新分配 PID，导致幂等只在 Producer 与 Broker 的同一次会话中有效，新建立的会话会重新开始计算。

消费端

Broker 多次投递同一条消息给 Consumer，Consumer 在消费时，需要幂等的消费消息，才能保证系统状态的正确性。

幂等消费常用的方案:

数据库唯一键约束去重
Redis + TTL 去重
状态机幂等

数据库唯一键约束

设计思路:

设计一张消费表，每个消息中携带一个全局唯一的 ID，
消费时先 insert 记录
如果插入成功，表示第一次消费，接着执行业务逻辑
如果插入失败，表示已经消费过，直接返回 ACK 即可。

适用场景: 消息会落库/业务的最终状态在数据库中

@KafkaListener(topics = "order.created", groupId = "order-group")
public void onMessage(ConsumerRecord<String, String> record, Acknowledgment ack) {
    String eventId = extractEventId(record); // 从 header/payload 提取

    // 1) 先做“去重标记”
    boolean first = consumedRepo.tryMarkConsumed(
        "order-group",
        record.topic(),
        record.partition(),
        record.offset(),
        eventId
    );

    if (!first) {
        // 重复消息：直接 ack，推进 offset（否则会无限重复拉到）
        ack.acknowledge();
        return;
    }

    try {
        // 2) 执行业务
        orderService.handleCreated(record.value());

        // 3) 业务成功后提交 offset
        ack.acknowledge();
    } catch (Exception e) {
        // 业务失败：不 ack，让 Spring Kafka 的重试/DLT 接管
        throw e;
    }
}

Redis + TTL

设计思路:

使用 SETNX 指令，将消息唯一 ID 作为 Key, Key 对应的 value 随意，建议设置成数字，节省内存空间
设置 TTL
如果 SETNX 指令返回 true，说明是第一次消费，继续执行业务逻辑
如果 SETNX 指令返回 false, 说明已经消费过了，直接返回 ACK

适用场景:

业务结果不一定落 DB
需要极高吞吐
能接受 TTL 窗口内去重（通常足够）

@Service
public class RedisIdempotencyService {
    private final StringRedisTemplate redis;

    public RedisIdempotencyService(StringRedisTemplate redis) {
        this.redis = redis;
    }

    /** @return true=首次消费，false=重复 */
    public boolean tryAcquire(String key, Duration ttl) {
        Boolean ok = redis.opsForValue().setIfAbsent(key, "1", ttl);
        return Boolean.TRUE.equals(ok);
    }

    /** 可选：失败时释放（谨慎使用） */
    public void release(String key) {
        redis.delete(key);
    }
}

@KafkaListener(topics = "order.created", groupId = "order-group")
public void onMessage(ConsumerRecord<String, String> record, Acknowledgment ack) {
    String eventId = extractEventId(record);
    String idemKey = "kafka:idem:order-group:" + eventId;

    boolean first = idem.tryAcquire(idemKey, Duration.ofDays(3));
    if (!first) {
        ack.acknowledge();
        return;
    }

    try {
        orderService.handleCreated(record.value());
        ack.acknowledge();
    } catch (Exception e) {
        // 这里是否 release？——通常不建议直接 release
        // 因为如果业务已部分成功但你没感知到，release 会导致重复执行更危险
        throw e;
    }
}

注意:

不要轻易的释放 redis 中用于判断消息是否被处理过的 key，否则可能会出现重复消费问题
key 的 TTL 一定要合理设置。

状态机幂等

设计思路: 状态之间的转换关系是确定的，例如: CREATED -> PAID -> SHIPPED -> FINISHED，重复消费消息只会尝试做同样的状态转换，不会造成副作用。

适用场景: 订单、支付、物流、账户等状态流转型业务

状态转换的逻辑: 当前状态 + 输入事件 => 新状态

-- 只有当状态还是 CREATED 才能推进到 PAID
UPDATE orders
SET status = 'PAID', paid_time = NOW()
WHERE order_id = ? AND status = 'CREATED';

Java 代码

@KafkaListener(topics = "order.created", groupId = "order-group")
public void onMessage(ConsumerRecord<String, String> record, Acknowledgment ack) {

    int updated = jdbcTemplate.update(sql, orderId);
    if(updated == 0) {
	    // 可能已经处理过，也可能是乱序消息
	    
	    // 假设有 1 -> 2 -> 3 -> 4 这 4 种状态转换
	    // 记录的当前状态是 3
	    // 此时来了一个从 1 -> 2 的状态转换的消息
	    // 由于当前状态是 3，因此消息是处理过了，直接丢弃
	    // 处理过的消息也可以用 redis 快速去重
	    if(isPrevStateMessage(record)) {
		    ack.acknowledge();
		    return;
	    }
	    
	    // 假设有 1 -> 2 -> 3 -> 4 这 4 种状态转换
	    // 记录的当前状态是 1
	    // 此时来了一个从 2 -> 3 的状态转换消息，这个就是乱序消息
	    // 如果是乱序消息，将当前消息重新入队或者是发送到其他队列，并回复 ack
	    if(isOutOfOrderMessage(record)) {
		    kafkaTemplate.send(record);
		    ack.acknowledge();
		    return;
	    }
	    
	    // 如果是重复消息，直接回复 ACK
	    ack.acknowledge();
      return;
    }

		// 第一次消费，执行相关业务逻辑
    try {
        orderService.handleCreated(record.value());
        ack.acknowledge();
    } catch (Exception e) {
        throw e;
    }
	
	// ....
}

如何在消费端实现 Exactly Once 语义

消费端需要处理的问题:

重复消费
乱序消费

有状态的消息和无状态的消息

有状态的消息: 例如订单，有明确的 CREATED -> PAID -> SHIPPED -> FINISHED 状态转换
无状态的消息: 例如点赞，每一次点赞都是一种全新的状态

实现方式

有状态

有状态的消息实现步骤:

Redis 去重，判断是否处理过(可选)
乱序消息直接 ACK 并重新入队
执行业务幂等 SQL
将消息已处理过的信息写入 Redis 并加上恰当的 TTL

无状态

无状态的消息实现步骤:

单独增加一张数据库表，例如: user_assets_message，用于持久化记录消息是否被处理
Redis 去重，判断是否处理过(可选)
~~乱序消息直接 ACK 并重新入队~~(有状态的消息才会出现乱序的现象)
查询数据库，当前消息是否已经被处理过(最后一步的 Redis 写入失败)
执行业务 SQL 以及消息是否被处理的 SQL，这两个 SQL 必须处于同一个事务中
将消息已经处理过的信息写入 Redis 并加上恰当的 TTL(可选)

思考

重复消费，乱序消费本身是一个小概率事件，是否有必要还加上 Redis 来去重? 大部分的业务都是不需要加上 Redis 来去重的，业务中出现如下的情况时，加上 Redis 去重才有意义:

重复执行的代价太高

如何设置重试以及死信队列?

Kafka 自身是不支持死信队列，但是 spring-kafka 提供了消费重试以及重试失败后将消息发送到指定队列的能力。

关闭自动提交 + 手动 ack

spring:
  kafka:
    consumer:
      enable-auto-commit: false
      auto-offset-reset: earliest
    listener:
      ack-mode: manual_immediate

配置错误处理器: 重试 N 次，最终进入 DLT(Dead Letter Topic)

@Configuration
public class KafkaDltConfig {

    @Bean
    public DefaultErrorHandler errorHandler(KafkaTemplate<Object, Object> template) {

        // 把失败消息发布到 DLT 的“发布器”
        DeadLetterPublishingRecoverer recoverer =
                new DeadLetterPublishingRecoverer(template,
                        (record, ex) -> new TopicPartition(record.topic() + ".DLT", record.partition()));

        // 重试策略：例如重试 3 次，每次间隔 1s（固定退避）
        FixedBackOff backOff = new FixedBackOff(1000L, 3L);

        DefaultErrorHandler handler = new DefaultErrorHandler(recoverer, backOff);

        // 不可重试异常：直接进 DLT（避免白重试）
        handler.addNotRetryableExceptions(
                IllegalArgumentException.class,
                ValidationException.class
        );

        // 可选：记录日志（默认也会打）
        handler.setRetryListeners((record, ex, deliveryAttempt) -> {
            // deliveryAttempt: 第几次投递（1 开始）
        });

        return handler;
    }

    @Bean
    public ConcurrentKafkaListenerContainerFactory<Object, Object> kafkaListenerContainerFactory(
            ConsumerFactory<Object, Object> consumerFactory,
            DefaultErrorHandler errorHandler) {

        ConcurrentKafkaListenerContainerFactory<Object, Object> factory =
                new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(consumerFactory);
        factory.setCommonErrorHandler(errorHandler);

        // 你希望手动 ack 的话，确保这里是 MANUAL 或 MANUAL_IMMEDIATE（也可放 YAML）
        factory.getContainerProperties().setAckMode(ContainerProperties.AckMode.MANUAL_IMMEDIATE);

        return factory;
    }
}

关键点: @KafkaListener 注解修饰的方法不要捕获异常，从而交给错误处理器去处理，如果 @KafkaListener 注解修饰的方法捕获了异常，导致调用方无法感知到异常，错误处理器就无法起作用。

缓存一致性协议以及读写屏障

Tue, 04 Nov 2025 20:23:54 +0800

今天将从 CPU 的发展历程，来了解缓存一致性协议，Store Buffer, Store Forwarding, Invalidate Buffer, 可见性，重排序(Reorder)，读屏障和写屏障

单核架构

计算机的两个核心部件: CPU 和内存。CPU 负责计算，内存负责存储指令以及指令所需的数据:

由于 CPU 的处理速度远远大于从内存获取数据的速度，因此工程师在内存和 CPU 之间加了一层缓存:

在单核 CPU 架构下，只能够通过提升 CPU 频率来提升性能，导致功耗急剧上升，从而出现了多核 CPU 架构。但是多核架构下需要处理一个问题，那就是缓存如何进行设计? 有两种方案:

多个 CPU 核心共享高速缓存
每个 CPU 核心管理自己的高速缓存

第一种方案实现比较简单，但是每个核心访问缓存之前需要获取访问缓存的权限，也就是锁，在获取到锁之前需要等待，等待期间会浪费很多 CPU 的性能。

第二种方案因为每个核心拥有自己的缓存，不需要获取锁，因此性能相对于第一种方案更高，这也是目前 CPU 使用的一种方案:

每个核心拥有自己的缓存，处于不同核心上的进程，因为进程 A 不能够修改进程 B 的数据，所以可以放心的修改各自缓存中的数据，但是如果同一个进程的多个线程分配在了不同的核心上，就不能够随意的修改各自缓存中的数据了。因为进程是资源分配的最小单位，同一个进程中的多个线程共享进程的资源，因此多线程环境下需要保证缓存的一致性。目前常用的缓存一致性协议是 MESI 协议。

MESI 协议

MESI(Modify, Exclusive, Shared, Invalid) 硬件缓存一致性协议确保所有核心看到的数据是一样的。在硬件层面实现了缓存一致性。

在缓存行中会有一个标志位表示当前缓存行的状态:

M(Modified): 表示缓存行被修改过，是所有缓存中唯一有效(最新)的数据，还未写入内存，与内存中的数据不一致。
E(Exclusive): 表示缓存数据未被修改，只在当前核心的缓存中存在，其他核心的缓存中不存在，是所有缓存中唯一的副本，与内存中的数据一致。
S(Shared): 表示缓存行至少被 2 个核心缓存过，并且没有被修改，与内存中的数据保持一致。写缓存行之前，必须先让其他核心中的缓存行失效。
I(Invalid): 表示缓存行无效，需要重新从内存或其他核心的缓存中加载最新的数据

在 MESI 协议下，核心 C1 写入缓存行 A 之前，需要通知其他的核心将缓存行 A 标记为无效，其他核心收到通知后，将缓存行 A 标记为无效，并需要给核心 C1 返回 ACK 确认，核心 C1 收到全部的 ACK 确认后才会更新缓存行 A，并将缓存行 A 的状态改成 Modifed。

  sequenceDiagram
    participant C1 as 核心 C1
    participant C1C as C1 缓存
    participant Bus as 总线
    participant S2 as 核心 C2 
    participant S3 as 核心 C3
    participant S4 as 核心 C4

    C1->>Bus: 发送 "Invalidate A" 请求
    Bus->>S2: 广播失效通知 (Invalidate A)
    Bus->>S3: 广播失效通知 (Invalidate A)
    Bus->>S4: 广播失效通知 (Invalidate A)

    S2->>S2: 将 A 标记为无效
    S3->>S3: 将 A 标记为无效
    S4->>S4: 将 A 标记为无效

    S2-->>Bus: 发送 ACK
    S3-->>Bus: 发送 ACK
    S4-->>Bus: 发送 ACK

    Bus-->>C1: 所有 ACK 已收到

    C1->>C1C: 写入缓存行 A，状态变为 Modified

通过上面的流程图可以看到，从发送 Invalidate 通知到最终修改缓存行这段期间，CPU 必须等待，这非常的浪费 CPU 的性能，因此工程师在 CPU 和缓存之间加了一个 Store Buffer

Store Buffer 和读写屏障

Store Buffer 的作用是将数据放入 Store Buffer 中，等收到全部的 ACK 之后，再将 Store Buffer 中的数据写入缓存中，这样 CPU 无需等待，继续执行其他的指令。CPU 获取数据数据时，每个 CPU 核心可以扫描自身的 Store Buffer, 但是不能够访问其他 CPU 核心的 Store Buffer。

Store Forwarding

CPU 虽然可以不用等待，但是这样会将 Invalidate 操作变成了一个异步的行为，这带来了一个可见性问题，看下面的代码:

public class InvalidateTest{
	private int a = 0;
	private int b = 0;
	
	public void foo() {
		a = 1;
		int b = a + 1;
		System.out.println(b);
	}
}

假设现在缓存行中存在 a = 0，状态是 Shared，我们看一下执行过程:

执行 a = 1，因为缓存行的状态是 Shared，所以需要通知其他的核心，将 a = 1 写入 Store Buffer 中，发送 Invalidate 通知，CPU 继续执行
执行 int b = a + 1;。读取缓存行中 a 的值，此时 a = 0, 因此最后 b 的值为 1 而不是 2

之所以会出现上面的问题，是因为 CPU 没有读取 Store Buffer 中 a 的最新值，而是读取的缓存行中已经过期了的值，因此硬件工程师设计让 CPU 先读取 Store Buffer 中的内容，没有找到再读取缓存中的内容，这个过程叫做 Store Forwarding。

写屏障

public class InvalidateTest{
	private int a = 0;
	private int b = 0;
	private int c = 0;
	
	public void foo() {
		a = 1;
		b = 1;
	}
	
	public void boo() {
		while(b == 0) continue;
		assert(a == 1);
	}
}

看下上面的代码: assert(a == 1) 一定会断言成功吗? 答案是不一定，看下下面的执行顺序:

假设核心 C1 执行 foo() 方法，核心 C2 执行 boo() 方法。C1 缓存中存在 a = 0, 状态是 Shared 和 b = 0, 状态是 Exclusive 独占状态，C2 缓存中存在 a = 0 状态是 Shared

C1 执行 a = 1, 由于状态是 Shared, 需要发送 Invalidate 通知并写入 Store Buffer
C1 执行 b = 1, 由于是 Exclusive 的状态，无需发送 Invalidate 通知，直接写入缓存行，并将状态修改成 Modified
C2 执行 while 循环，由于 b 不在缓存中，发出 Read 通知，C1 收到消息 Read 消息后，发现拥有 b 的最新版本，将 b = 1 发送给 C2, 并将 b = 1 的缓存行状态设置成 Shared
C2 收到 b = 1 后，同样将 b = 1 的缓存行状态设置成 Shared，同时退出 while 循环
C2 执行 assert(a == 1)，由于缓存中存在 a = 0，状态是 Shared，并且此时还未收到 a 的 Invalidate 通知，因此 a == 1 断言失败
C2 接收到 C1 关于 a 的 Invalidate 通知

根据上面的执行流程就好像: b = 1 先于 a = 1 执行，这就是所谓的乱序执行(Reorder)。从单个核心上来看，执行的顺序并没有变，由于 Invalidate 通知是一个异步操作，如果消息通知的不够及时，就会导致一个乱序问题的操作。

这个问题该怎么解决呢? 答案是写屏障，写屏障的作用: 写屏障之后的写缓存操作执行之前，必须先将 Store Buffer 中的写操作先同步到缓存中。

如果写屏障是要等 Invalidate ACK，那就又回到了没有 Store Buffer 的场景。现代 CPU，写屏障的实现方式是强制将写屏障之后的写操作全部写入 Store Buffer, 而不能直接写缓存，这样一个个的排队就不会出现上述的乱序问题了。

Invalidate Buffer 和读屏障

通过 Store Buffer 和 Store Forwarding 虽然解决了可见性问题，如果写缓存的操作非常多，Invalidate ACK 回复的又非常慢，导致 Store Buffer 很快就被填满，CPU 就又只能够等待 Store Buffer 可用，硬件工程师为了解决 ACK 回复慢的问题，引入了 Invalidate Buffer。

核心收到 Invalidate 通知后，立马回复 Invalidate ACK, 并将 Invalidate 操作写入 Invalidate Buffer 中。

获取数据时，CPU 核心不能够扫描 Invalidate Buffer 来判断缓存是否 Invalidate(过期)

同样的，引入 Invalidate Buffer 将 Invalidate 操作变成了异步操作，也是会导致一个可见性问题，看下面的代码:

public class InvalidateTest{
	private int a = 0;
	private int b = 0;
	private int c = 0;
	
	public void foo() {
		a = 1;
		int b = a + 1;
		System.out.println(b);
	}
	
	public void boo() {
		int c = a + 1;
		System.out.println(b);
	}
}

假设核心 C1 执行 foo() 方法，核心 C2 执行 boo() 方法。C1 和 C2 的缓存行中都存在 a = 0;

C1 执行 a = 1, 发送 Invalidate 通知给 C2
C2 收到 Invalidate 通知后立马回复 ACK，并将 Invalidate 操作写入 Invalidate Buffer
C2 执行 int c = a + 1 的操作，由于 Invalidate 操作还在 Invalidate Buffer 中，还未执行，因此变量 a 所在的缓存行生效，a 的值为 0，最后 b 的值为 1

如果没有 Invalidate Buffer, C2 需要现将 a 所在的缓存行标记为过期，再回复 ACK，这样执行 int c = a + 1 的时候，a 所在的缓存行已经过期，C2 需要读取 a 的最新值。

那怎么解决这个可见性的问题呢? 答案是读屏障，读屏障的作用是将 Invalidate Buffer 中的指令全部执行完之后才会继续执行读屏障后的指令，通过读屏障，就可以解决解决 Invalidate Buffer 带来的可见性问题了。

可见性

invalidate buffer 将 invalidate(过期/失效) 指令放入 invalidate buffer，并立即回应 invalidate ack。CPU 在真正执行 invalidate 指令之前的空档期，如果读取了本应该已经过期但是实际上没有过期的缓存行就会出现可见性的问题。

invalidate 指令的作用是将某个缓存行标记为过期，标记缓存行里面的数据是旧的，不是最新的数据，需要重新从内存或缓存中读取最新的数据，但是 invalidate 指令被放入 Invalidate Buffer 中延迟执行，在 invalidate 指令执行之前又出现了读本应该过期的缓存行，就出现了读取旧值，而非最新值的情况，从而出现了可见性问题。

BIO NIO AIO

Wed, 29 Oct 2025 17:06:43 +0800

BIO,NIO,AIO 对应三种不同的 IO 模型，本文将详细介绍这三种 IO 模型。

同步和异步

同步: 任务顺序执行，必须等前一个任务完成后才可以继续执行后面的任务
异步: 任务发起后，不用等待任务完成，可以忙其他的任务，当任务完成时，会主动进行通知

同步和异步主要的区别在于任务完成时是否有通知(回调)机制，如果没有所谓的通知(回调)机制，那就是同步的，如果有通知(回调)机制，那就是异步。不能够通过是否阻塞来判断是同步还是异步

代码示例

// 同步调用，readFile 方法执行时阻塞等待文件读完
String data = readFile("file.txt");
System.out.println("文件内容: " + data);

在 readFile 没有读取完毕之前，程序不会往下执行

// 异步调用，方法立即返回
readFileAsync("file.txt", new Callback() {
    @Override
    void onComplete(String data) {
        System.out.println("文件内容: " + data);
    }
});

System.out.println("我不用等文件读完，先去干别的事");

readFileAsync 调用后立即返回，不阻塞
文件读取完毕后，调用 onComplete 通知读取的结果

阻塞和非阻塞

阻塞与非阻塞指的是线程的状态。

阻塞: 指的是 I/O 操作的这段时间，线程处于阻塞状态，等待 I/O 操作完成后唤醒线程并继续往下执行
非阻塞: 指的是 I/O 操作的这段时间，线程处于非阻塞(运行态)状态。线程发起 I/O 操作，发现数据不可用时，立即返回，不等待，继续向下执行。

代码示例

// 同步调用，readFile方法执行时阻塞等待文件读完
String data = readFile("file.txt"); // 阻塞等待 IO 完成
System.out.println("文件内容: " + data);

执行 readFile 时，线程处于阻塞状态，等待 IO 完成

FileChannel fileChannel = FileChannel.open(path, StandardOpenOption.READ);
ByteBuffer buffer = ByteBuffer.allocate(1024);

// 不阻塞，直接向下执行
int bytesRead = fileChannel.read(buffer); 

// 由于没有回调(通知)机制，只能够不断的轮询
while (bytesRead != -1) {
	buffer.flip();
	System.out.println("读取的内容: " + StandardCharsets.UTF_8.decode(buffer));
	buffer.clear();
	bytesRead = fileChannel.read(buffer);
}

fileChannel.close();

执行 read 方法的时候，如果没有数据，直接返回 0，不阻塞等待
因为没有回调(通知)机制，只能够通过 while 循环来判断 IO 操作是否完成

BIO

Blocking I/O(BIO)，是一种同步阻塞的 IO 模型。线程执行 IO 操作时会进入阻塞状态，直到 IO 操作完成时，被唤醒再继续往下执行。线程与 IO 操作的关系是一对一，也就是一个线程对应一个 IO 操作

代码示例

import java.io.FileInputStream;
import java.io.IOException;

public class BioFileReadExample {
    public static void main(String[] args) {
        String filePath = "test-bio.txt";

        try (FileInputStream fis = new FileInputStream(filePath)) {
            byte[] buffer = new byte[1024];
            int bytesRead;

            // 阻塞式读取，read()会阻塞直到有数据或文件结束
            while ((bytesRead = fis.read(buffer)) != -1) {
                String content = new String(buffer, 0, bytesRead, "UTF-8");
                System.out.print(content);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

NIO

Non-Blocking I/O(NIO), 是一种同步非阻塞的 IO 模型。线程发起 IO 操作后，不会进入阻塞状态等待 IO 操作的完成，而是直接往下继续执行。线程与 IO 操作的关系是一对多，也就是一个线程可以管理多个 IO 操作。

NIO 相较于 BIO 多了一个选择器(Selector)组件，由选择器来管理多个 IO 操作，线程直接与选择器进行对话。

代码示例

// NIO 服务器示例，非阻塞IO，单线程可同时处理多个连接
ServerSocketChannel serverChannel = ServerSocketChannel.open();
serverChannel.bind(new InetSocketAddress(8080));
serverChannel.configureBlocking(false);  // 非阻塞模式

Selector selector = Selector.open();
serverChannel.register(selector, SelectionKey.OP_ACCEPT);

while (true) {
    selector.select();  // 阻塞，等待某个通道准备好事件（连接读写等）

    Set<SelectionKey> selectedKeys = selector.selectedKeys();
    Iterator<SelectionKey> iter = selectedKeys.iterator();

    while (iter.hasNext()) {
        SelectionKey key = iter.next();
        iter.remove();

        if (key.isAcceptable()) {  // 有新连接
            ServerSocketChannel ssc = (ServerSocketChannel) key.channel();
            SocketChannel clientChannel = ssc.accept();
            clientChannel.configureBlocking(false);
            clientChannel.register(selector, SelectionKey.OP_READ);
            System.out.println("Accepted new connection");
        } else if (key.isReadable()) {  // 有数据读
            SocketChannel clientChannel = (SocketChannel) key.channel();
            ByteBuffer buffer = ByteBuffer.allocate(1024);
            int bytesRead = clientChannel.read(buffer);
            if (bytesRead == -1) {
                clientChannel.close();
            } else {
                buffer.flip();
                byte[] data = new byte[buffer.limit()];
                buffer.get(data);
                System.out.println("Received: " + new String(data));
            }
        }
    }
}

AIO

Asynchronous I/O(AIO), 是一种异步非阻塞的 IO 模型。线程发起 IO 操作后，不会等待 IO 操作的完成，而是继续往下执行，但是当 IO 操作完成后，会主动通知线程 IO 操作完毕。相较于 NIO 模型，加上了一个主动通知的功能，避免了轮训带来的性能损耗。

代码示例

import java.nio.ByteBuffer;
import java.nio.channels.AsynchronousFileChannel;
import java.nio.channels.CompletionHandler;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;
import java.nio.charset.StandardCharsets;
import java.io.IOException;
import java.util.concurrent.CountDownLatch;

public class AioFileExample {

    public static void main(String[] args) throws Exception {
        String filePath = "test-aio.txt";

        // 计数器，等待异步操作完成
        CountDownLatch latch = new CountDownLatch(2);

        // 异步写入示例
        asynchronousWrite(filePath, "Hello AIO World!\n", latch);

        // 等待写入完成，再开始读取（简化处理，实际可用回调链式调用）
        latch.await();

        // 重置计数器用于读取
        latch = new CountDownLatch(1);

        // 异步读取示例
        asynchronousRead(filePath, latch);

        // 等待读取完成
        latch.await();

        System.out.println("所有异步操作完成");
    }

    // 异步写入文件
    public static void asynchronousWrite(String filePath, String content, CountDownLatch latch) throws IOException {
        AsynchronousFileChannel fileChannel = AsynchronousFileChannel.open(
                Path.of(filePath),
                StandardOpenOption.WRITE, StandardOpenOption.CREATE);

        ByteBuffer buffer = ByteBuffer.wrap(content.getBytes(StandardCharsets.UTF_8));

        // 异步写，写完调用回调
        fileChannel.write(buffer, 0, null, new CompletionHandler<Integer, Void>() {
            @Override
            public void completed(Integer result, Void attachment) {
                System.out.println("写入完成，字节数: " + result);
                try {
                    fileChannel.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
                latch.countDown();  // 计数减1，表示写入完成
            }

            @Override
            public void failed(Throwable exc, Void attachment) {
                System.err.println("写入失败: " + exc);
                latch.countDown();
                try {
                    fileChannel.close();
                } catch (IOException e) { e.printStackTrace();}
            }
        });
    }

    // 异步读取文件
    public static void asynchronousRead(String filePath, CountDownLatch latch) throws IOException {
        AsynchronousFileChannel fileChannel = AsynchronousFileChannel.open(
                Path.of(filePath),
                StandardOpenOption.READ);

        ByteBuffer buffer = ByteBuffer.allocate(1024);

        // 异步读，读完调用回调
        fileChannel.read(buffer, 0, buffer, new CompletionHandler<Integer, ByteBuffer>() {
            @Override
            public void completed(Integer result, ByteBuffer attachment) {
                System.out.println("读取完成，字节数: " + result);
                attachment.flip();
                byte[] data = new byte[attachment.limit()];
                attachment.get(data);

                String content = new String(data, StandardCharsets.UTF_8);
                System.out.println("文件内容: \n" + content);
                try {
                    fileChannel.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
                latch.countDown();  // 计数减1，表示读取完成
            }

            @Override
            public void failed(Throwable exc, ByteBuffer attachment) {
                System.err.println("读取失败: " + exc);
                latch.countDown();
                try {
                    fileChannel.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        });
    }
}

Java 中 return, try catch finally 的执行顺序

Tue, 28 Oct 2025 13:29:27 +0800

return 语句对应两条汇编指令:

将返回值写入到某个寄存器中
执行 ret 指令返回到调用函数的位置。

在 Java 中，在这两个指令之间可以插入很多其他的指令，比如 finally 代码块中的指令。对于有 finally 语句的代码，执行到 return 语句时，先将返回值放入到返回值寄存器中，然后继续执行 finally 代码块中的指令。理解了这一点就非常容易理解下面这些代码的执行顺序:

public static int getInt() {
    int a = 10;
    try {
        return a;
    } finally {
        a = 40;
    }
}

输出: 10

执行到 try 代码块中的 return a 语句时，先将 a 的值，也就是 10 放入到返回值寄存器中，然后执行 finally 代码块中内容。由于 finally 代码块中的指令并没有修改返回值寄存器里面的内容，所以寄存器里面的值还是 10。所以 getInt() 的返回值是 10。

再看一段在 finally 中修改返回值代码:

public static int getInt() {
    int a = 10;
    try {
        return a;
    } finally {
        a = 40;
        return a;
    }
}

输出: 40

根据我们上面的分析: try 代码块中的 return a 先将 a 的值，也就是 10 放入到返回值寄存器中，然后执行 finally 代码块中的内容，由于 finally 代码块中也有 return 语句，所以将 a 的值，也就是 40 放入到寄存器中，因此 getInt() 的返回值是 40。

再看下面的这段代码，返回值是多少呢?

public static int getInt() {
    int a = 10;
    try {
        System.out.println(a / 0);
        return a;
    } catch (ArithmeticException e) {
        a = 30;
        return a;
    } finally {
        a = 40;
    }
}

输出: 30

要理解为什么输出是 30, 就得知道 try, catch 和 fianlly 代码块的执行顺序了。只需要记住一点即可: fianlly 里面的语句永远是最后执行的。

由于 try 中发生异常，所以执行 catch 代码块中代码，执行到 return a; 语句时，将 a 的值也就是 30 放入到返回值寄存器中，因为有 finally 代码块，所以执行 finally 代码块中的语句，由于 finally 代码块中并没有 return 语句，所以返回值寄存器里面的内容没有发生变化，还是 30，所以 getInt() 的返回值是 30。

再看一段在 finally 中修改返回值代码:

public static int getInt() {
    int a = 10;
    try {
        System.out.println(a / 0);
        return a;
    } catch (ArithmeticException e) {
        a = 30;
        return a;
    } finally {
        a = 40;
        return a;
    }
}

输出: 40

这段代码就不解释了。

总结

return 语句对应两条汇编指令: 将返回值放入到返回值寄存器中 + 返回到调用函数的地方
在 return 两条汇编指令之间可以插入 fianlly 代码块中的指令。
在执行 finally 代码块中的指令之前，会先执行 return 的第一条汇编指令: 将返回值写入到返回值寄存器中
finally 其实是语法糖，让代码更为的简洁，避免代码冗余。如果没有 fianlly 语法糖，就需要将 finally 代码块中的指令在 try 和 catch 中都放一份。

如何动态创建一个 Feign 客户端

Tue, 22 Jul 2025 15:19:11 +0800

在使用 open feign 的时候，我们都是直接在接口上添加 @FeignClient 注解， open feign 会通过服务发现，自动生成接口的实现类并交给 Spring 容器来管理。如果我们已知服务的地址，想直接进行调用，可以手动生成 Feign 客户端:

import feign.Feign;
import feign.Target;
import feign.codec.Decoder;
import feign.codec.Encoder;
import feign.jackson.JacksonDecoder;
import feign.jackson.JacksonEncoder;
import org.springframework.cloud.openfeign.support.SpringMvcContract;

/**
 * 动态构建RPC客户端
 */
public class FeignClientBuilder<T> {

    private Encoder encoder = new JacksonEncoder();
    private Decoder decoder = new JacksonDecoder();

    private Class<T> targetClass;

    public FeignClientBuilder(Class<T> targetClass) {
        this.targetClass = targetClass;
    }

  	// instanceHost: http://192.168.0.3:8088
    public T build(String instanceHost) {

        Feign.Builder builder = Feign.builder()
                .encoder(encoder)
                .decoder(decoder)
                .requestInterceptor(template -> {
                        template.header("Content-Type", "application/json");
                })
          			// 指定 Feign 如何解析注解。 使用 SpringMvcContract 让 Feign 能够理解 SpringMVC 的注解
          			// 例如 @RequestMapping, @GetMapping 等
          			.contract(new SpringMvcContract());

        // 显式指定 name 和 URL
        Target<T> target = new Target.HardCodedTarget<>(
                targetClass,
                instanceHost,  // 自定义唯一标识
                instanceHost
        );
        return builder.target(target);
    }

}

上述代码适合已知服务地址直接进行调用的情况。

如何存储密码?

Fri, 18 Jul 2025 16:16:34 +0800

前言

在系统中存储密码时，密码是不能够明文进行存储的，这样密码泄漏后，攻击者无法轻易(或者几乎不可能)还原出用户的原始密码，从而避免用户数据被破坏。

加密和哈希

加密：不论是对称加密还是非对称加密，只要密钥匹配，就可以将密文进行还原。比较适合双方需要进行沟通的场景，例如通话，发送方先对数据加密之后再传输，防止中间人窃听，接收方收到密文后，使用特定的密钥进行解密。
哈希：是单向的，相同的数据经过同一个哈希算法后，会生成相同的哈希值，这个哈希值无法被还原成原始数据。

所以对于密码的存储我们需要使用哈希算法，而非加密算法，这样即使攻击者获取到了密码的哈希值，也无法通过哈希值推导出用户的密码。

黑客破解密码的手段

虽然密码会使用哈希算法来进行转换，但是如果哈希算法选择不对的话，黑客还是可以很容易的破解出用户的密码，黑客常见的攻击手段：

字典攻击：使用包含大量常用密码的字典来匹配。
彩虹表攻击：使用提前计算好的哈希值集合来进行匹配。

如何选择哈希算法

哈希算法的特点是相同的输入会有相同的输出，如果单纯的将密码进行哈希计算，会出现黑客破解了一个密码，其他具有相同哈希值的用户也会攻破。因此在将密码进行哈希之前还需要加盐(salt)，并且每个用户的盐是随机的，将密码和随机的盐拼接之后再进行哈希。通过加随机盐的方式，相同的密码由于盐不同，拼接后生成的哈希值不同，黑客每次就只能够破解一个密码，从而增加黑客破解密码的成本。

虽然加盐大大增加了黑客破解密码的成本，随着计算机算力的提升，尤其是 GPU 的并行计算能力，简单的加盐密码被破解的几率还是很大，因此我们还需要一种计算速度相对较慢的哈希算法，这样可以让每秒尝试密码的次数大大降低，而对于普通用户而言，慢个几十毫秒是完全可以接受的。

通过上面的描述，存储密码比较理想的算法应该具备以下的特点：

单向的
带盐的
计算速度较慢的

通用哈希算法(MD5, SHA-1, SHA-256, SHA-512)是不能够用来处理密码的，因为它们的计算速度太快了，很容易被现代 GPU 给攻破。给密码加密应该选择下面的哈希算法：

Argon2：当前最优的算法，2015年密码哈希竞赛 (Password Hashing Competition) 的获胜者，被公认为目前最强的密码哈希算法。它不仅可以调整时间成本（CPU消耗），还可以调整内存成本，能有效抵抗 GPU 和 ASIC（专用集成电路）的破解。推荐使用 Argon2id 版本，它结合了 Argon2d 和 Argon2i 的优点，提供了对侧信道攻击和 GPU 破解最好的防护
Bcrypt：可靠且被广泛使用，它内置了盐并且有一个可以调整的代价因子(Cost Factor)。
Scrypt：它是一个“内存困难型”(memory-hard)算法，需要大量内存，这使得利用 GPU 进行大规模并行破解的成本非常高。相比 Argon2，它的灵活性稍微差一点。

优先使用 Argon2，如果系统不支持再选择 Bcrypt 算法。这两个算法生成的哈希值都自带了盐，因此在做数据库设计的时候，可以省略一个字段。

Argon2 和 Bcrypt 在 Java 中的使用

在 pom.xml 文件中新增依赖:

<dependency>
    <groupId>com.password4j</groupId>
    <artifactId>password4j</artifactId>
    <version>1.8.4</version>
</dependency>

代码示例:

public static void bcryptEncode() {
    String raw = "888888";
    BcryptFunction instance = BcryptFunction.getInstance(Bcrypt.B, 12);
    Hash hashObj = Password.hash(raw).with(instance);
    String encodedText = hashObj.getResult();
    System.out.println("encodedText: " + encodedText);
}


public static void bcryptDecode() {
    String raw = "888888";
    String encodedText = "$2b$12$Wlm/wmfozYi5UQbMhMbqMOF2qo4RNleLIGSOiSo2BNF0yVNnRRhiO";
    BcryptFunction instance = BcryptFunction.getInstanceFromHash(encodedText);
    boolean result = Password.check(raw, encodedText).with(instance);
    System.out.println(result);
}

public static void argon2Encode() {
    String raw = "888888";
    Argon2Function instance = Argon2Function.getInstance(4096, 20, 4, 32, Argon2.ID);
    Hash hashObj = Password.hash(raw).addRandomSalt(64).with(instance);
    String encodedText = hashObj.getResult();
    System.out.println(encodedText);
}

public static void argon2Decode() {
    String raw = "888888";
    String encoded = "$argon2id$v=19$m=4096,t=20,p=4$OjcuB72RlQLfIlfwwUrv+6Ibh8DX1FUbK5ofDg8AqrKqYzsju+c/dBwBvntGnc0s5+rEhLO3254AlLmnDG/qrg$2e56eWHaPOtZpGKGpFyBmxxp92N+5thKPRtgmfPBU/Q";
    Argon2Function instance = Argon2Function.getInstanceFromHash(encoded);
    boolean result = Password.check(raw, encoded).with(instance);
    System.out.println(result);
}

为什么 ThreadLocal 可能会导致内存泄漏？

Sat, 05 Jul 2025 11:00:28 +0800

ThreadLocal 让我们非常方便的管理和使用各线程独独有的局部变量，但是如果使用不当，会导致内存泄漏。这篇文章将详细的介绍为什么 ThreadLocal 会发生内存泄漏，以及如何避免内存泄漏的发生。

内存泄漏

内存泄漏：占有内存空间，但是存储的数据无法被程序使用和释放，随着时间的推移，内存占用量越来越多，最终导致内存溢出。

Java的四种引用类型

强引用：在任何时候，都不会被垃圾回收器回收，我们正常的 = 赋值就是强引用
软引用：当内存不足的时候，会被垃圾回收器回收
弱引用：任何时候，只要发生了 GC，内存都会被回收
虚引用：最弱的引用类型，软引用和弱饮用好歹还可以使用 get 方法获取到对应的对象，虚引用什么也获取不到。主要的作用就是跟踪对象被垃圾回收器回收的活动。

详细解释

为什么要使用弱引用？

如果 Key 使用强引用，开发人员在使用不当的情况下，内存泄漏会更为严重，因为栈中的引用不再指向 ThreadLocal 对象时，Entry 中的 Key 是强引用，堆中的 ThreadLocal 对象永远都无法被回收：

使用弱引用时，如果外部没有强引用指向 ThreadLocal，那么 ThreadLocal 对象会被回收，因此 ThreadLocalMap 可以检查 Entry 中的 key 是否为 null 来判断 Entry 是否过期，从而释放因使用不当造成的内存泄漏。

ThreadLocal 如何尽可能的减少内存泄漏？

调用 set() 方法时，清除过期元素
调用 get() 方法时，清除过期元素
调用 remove() 方法时，清除过期元素

只要在访问 ThreadLocal 的过程过程中，遍历了底层的 Entry 数组，ThreadLocal 都会进行清除过期元素的操作，将清除元素的操作平坦到每一次基础的操作中。

// set 方法的逻辑：
// 1. 通过 key 找到 Entry 在数组中的位置 i
// 2. 从数组第 i 个位置开始遍历，直到找到 key 对应的元素或者找到已过期的元素
// 		2.1 如果找到 key 对应的元素，直接设置值，然后返回
// 		2.2 如果找到过期的元素，将过期的元素删除，并将过期元素所在的位置设置成 set 方法传递过来的 key 和 value
private void set(ThreadLocal<?> key, Object value) {
    Entry[] tab = tableh;
    int i = key.threadLocalHashCode & (len-1);

    for (Entry e = tab[i];
         e != null;
         e = tab[i = nextIndex(i, len)]
        ) {
        ThreadLocal<?> k = e.get();

        if (k == key) {
            e.value = value;
            return;
        }

        // 如果 key 为 null，说明元素已经过期，进行删除
        if (k == null) {
            // 替换过期的元素
            replaceStaleEntry(key, value, i);
            return;
        }
    }

    tab[i] = new Entry(key, value);
    int sz = ++size;
    if (!cleanSomeSlots(i, sz) && sz >= threshold)
        rehash();
}


private void remove(ThreadLocal<?> key) {
    Entry[] tab = table;
    int len = tab.length;
    int i = key.threadLocalHashCode & (len-1);
    for (Entry e = tab[i];
         e != null;
         e = tab[i = nextIndex(i, len)]) {
        if (e.get() == key) {
            e.clear();
          	// 删除元素的同时，清理过期元素
            expungeStaleEntry(i);
            return;
        }
    }
}

// key 对应的元素存在且没有发生 hash 冲突，直接返回对应的值
// key 不存在或者是发生了 hash 冲突，遍历数组并清理过期元素
private Entry getEntry(ThreadLocal<?> key) {
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    if (e != null && e.get() == key)
        return e;
    else
        return getEntryAfterMiss(key, i, e);
}

private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
    Entry[] tab = table;
    int len = tab.length;

    while (e != null) {
        ThreadLocal<?> k = e.get();
        if (k == key)
            return e;
        if (k == null)
            expungeStaleEntry(i);
        else
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

// staleSlot 表示过期插槽的位置
private void replaceStaleEntry(ThreadLocal<?> key, Object value,
                                       int staleSlot) {
    Entry[] tab = table;
    int len = tab.length;
    Entry e;

    // slotToExpunge 变量用于存储第一个需要被清除的元素
  	int slotToExpunge = staleSlot;
  
  	// 1. 向前遍历，直到找到第一个没有存放 Entry 的 slot
  	// 2. 记录在遍历过程中最后遇到的应该清除的 slot 的位置
    for (int i = prevIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = prevIndex(i, len))
        if (e.get() == null)
            slotToExpunge = i;

  	
    for (int i = nextIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = nextIndex(i, len)) {
      
          ThreadLocal<?> k = e.get();

          // 向后遍历时，如果发现 key 对应的 entry 存在，重新设置 value 的值
          // 并将 key 对应的 entry 迁移到方法参数传递过来的已过期元素的位置上
          if (k == key) {
                e.value = value;

                tab[i] = tab[staleSlot];
                tab[staleSlot] = e;

                // 当前循环的作用是在数组 staleSlot 位置向后查找过期的元素，
                // slotToExpunge 变量的定义是：第一个需要被清除的元素
                // slotToExpunge == staleSlot 表明数组 staleSlot 位置前面没有过期的元素
                // 前面没有需要被清除的元素，第 i 个位置就是第一个需要被清除的元素，因此需要将 i 的值赋值给 slotToExpunge
                if (slotToExpunge == staleSlot)
                    slotToExpunge = i;
                cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
                return;
           }

      			// k == null 表示第 i 个元素需要被清除
      			// slotToExpunge == staleSlot 表示 staleSlot 前面没有需要被清除的元素，第 i 个位置就是第一个需要被清除的元素
      			// 因此需要将 i 的值赋值给 slotToExpunge
            if (k == null && slotToExpunge == staleSlot)
                slotToExpunge = i;
    }

  	// key 在数组中不存在，则把 key, value 放在 staleSlot 位置上
    tab[staleSlot].value = null;
    tab[staleSlot] = new Entry(key, value);

  	// 如果有过期的元素，则清除过期元素
    if (slotToExpunge != staleSlot)
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}

// 清除元素，并重新计算未过期元素在数组中的位置
// 返回从 staleSlot 向后遍历遇到的第一个没有存放元素的位置
private int expungeStaleEntry(int staleSlot) {
      Entry[] tab = table;
      int len = tab.length;

      // expunge entry at staleSlot
      tab[staleSlot].value = null;
      tab[staleSlot] = null;
      size--;

      // Rehash until we encounter null
      Entry e;
      int i;
  		// 边遍历边删除元素，同时对元素重新 hash，迁移元素到新的位置上
      for (i = nextIndex(staleSlot, len);
           (e = tab[i]) != null;
           i = nextIndex(i, len)) {
          ThreadLocal<?> k = e.get();
          if (k == null) {
              e.value = null;
              tab[i] = null;
              size--;
          } else {
              int h = k.threadLocalHashCode & (len - 1);
              if (h != i) {
                  tab[i] = null;

                  // Unlike Knuth 6.4 Algorithm R, we must scan until
                  // null because multiple entries could have been stale.
                  while (tab[h] != null)
                      h = nextIndex(h, len);
                  tab[h] = e;
              }
          }
      }
      return i;
}

// 时间复杂度 N * logN
// 返回是否清除过元素
private boolean cleanSomeSlots(int i, int n) {
    boolean removed = false;
    Entry[] tab = table;
    int len = tab.length;
    do {
        i = nextIndex(i, len);
        Entry e = tab[i];
        if (e != null && e.get() == null) {
            n = len;
            removed = true;
            i = expungeStaleEntry(i); // 时间复杂度 N
        }
    } while ( (n >>>= 1) != 0); // 时间复杂度 logN
    return removed;
}

ThreadLocal 的详细介绍

Thu, 03 Jul 2025 15:24:26 +0800

为什么需要 ThreadLocal

线程是最小的执行单元，多线程可以在同一时间同时执行相同的代码。如果多个线程在同一个对象或者是实例上执行，那么这些线程将共享对象或实例中的属性。同时每个线程都有它们自己的局部变量，但是这些局部变量如果不通过参数的方式传递，很难进行共享。

通过例子来解释是最好。假设有一个 Servlet，这个 Servlet 首先会获取用户的信息，然后执行一些其他的动作。

doGet(HttpServletRequest req, HttpServletReresponse resp) {
    User user = getLoggedInUser(req);
    doSomething();
    doSomethingElse();
    renderResponse(resp);
}

如果现在 doSomething() 和 doSomethingElse() 也需要用户信息，这个时候你该怎么办呢？你不能够把 user 变成一个实例变量或者是静态变量，因为其他的线程也会执行相同的代码, 可能出现用户信息被替换的情况。这时你可能会把用户信息作为一个参数传递给 doSomething() 和 doSomethingElse():

doGet(HttpServletRequest req, HttpServletReresponse resp) {
    User user = getLoggedInUser(req);
    doSomething(user);
    doSomethingElse(user);
    renderResponse(resp);
}

这种方式虽然临时解决了问题，但是这会让每个需要用户信息的方法都新增用户参数，并且随着时间的推移，如果又需要一些其他的信息呢？又增加参数吗？肯定不能够这么做，这大大增加了代码的维护难度，非常的不优雅。

更为优雅的处理方式是将用户相关的信息放入到 ThreadLocal 中:

StaticClass.java

class StaticClass {
  static private ThreadLocal<User> threadLocal = new ThreadLocal<>();

  static ThreadLocal<User> getThreadLocal() {
    return threadLocal;
  }
}

doGet(HttpServletRequest req, HttpServletResponse resp) {
  User user = getLoggedInUser(req);
  StaticClass.getThreadLocal().set(user)
  try {
    doSomething()
    doSomethingElse()
    renderResponse(resp)
  }
  finally {
    StaticClass.getThreadLocal().remove()
  }
}

然后在需要用户信息的地方在将其取出来：

User user = StaticClass.getThreadLocal().get()

什么是 ThreadLocal?

ThreadLocal 是 Java 提供的一个类，用于创建和管理线程的局部变量。每个线程都可以独立的访问和修改线程中的变量，而不影响其他的线程。ThreadLocal 的主要作用就是在多线程的环境下保存每个线程独有的数据，线程间互不影响，从而避免锁机制所带来的复杂性和额外的性能开销。

ThreadLocal 类似于一个中间件，它把对线程局部变量的操作进行了封装，通过 ThreadLocal 我们可以非常方便和优雅的访问和管理同一个线程中的局部变量。

ThreadLocal 的使用

有两种方式初始化 ThreadLocal：

// 1. 如果你希望局部变量有一个默认的初始值，可以使用这种方式
ThreadLocal<Integer> threadId = ThreadLocal.withInitial(() -> 2);

// 2. 没有默认值，直接 new 一个对象
ThreadLocal<integer> threadId = new ThreadLocal<>();

使用示例：

public class UserContext {
    private static ThreadLocal<User> userThreadLocal = new ThreadLocal<>();

    public static User getCurrentUser() {
        return userThreadLocal.get();
    }

    public static void setCurrentUser(User user) {
        userThreadLocal.set(user);
    }

    public static void clear() {
        userThreadLocal.remove();
    }
}

ThreadLocal 实现原理

前置代码

Thread.java

public class Thread implements Runnable {

    // ......

    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

    /*
     * InheritableThreadLocal values pertaining to this thread. This map is
     * maintained by the InheritableThreadLocal class.
     */
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;

    // ......
}

ThreadLocal.java

public class ThreadLocal<T> {
      // ......

      ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
      }

      protected T initialValue() {
          return null;
      }

      void createMap(Thread t, T firstValue) {
          t.threadLocals = new ThreadLocalMap(this, firstValue);
      }

      private T setInitialValue() {
          T value = initialValue();
          Thread t = Thread.currentThread();
          ThreadLocalMap map = getMap(t);
          if (map != null) {
              map.set(this, value);
          } else {
              createMap(t, value);
          }
          if (this instanceof TerminatingThreadLocal) {
              TerminatingThreadLocal.register((TerminatingThreadLocal<?>) this);
          }
          return value;
      }

      // ......
}

设置元素的流程

public class ThreadLocal<T> {
  
  	// .....
   
    public void set(T value) {
          Thread t = Thread.currentThread();
          ThreadLocalMap map = getMap(t);
          if (map != null) {
            	// key 是 ThreadLocal
              map.set(this, value);
          } else {
              createMap(t, value);
          }
      }
  
  	// .....
}

获取元素的流程

public class ThreadLocal<T> {
  	
  	// ......
  
    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
          	// key 是 ThreadLocal
            ThreadLocalMap.Entry e = map.getEntry(this); 
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }
  
  	// ......
}

删除元素

public class ThreadLocal<T> {
  	
  	// ......
  
   	public void remove() {
         ThreadLocalMap m = getMap(Thread.currentThread());
         if (m != null) {
             m.remove(this);
         }
    }
  
  	// ......
}

通过上述源码阅读可以知道，ThreadLocal 的关键就是 Thread 类里面的 threadLocals 属性。通过 ThreadLocal 声明的线程局部属性都会保存在 Thread 类的threadLocals 属性中，key 为 ThreadLocal，value 为用户设定的值。

InheritableThreadLocal

InheritableThreadLocal 对 ThreadLocal 进行了扩展，允许在创建子线程的时候将父线程中已存在的线程局部变量继承到子线程中。继承后，父线程和子线程对局部变量的修改是独立的，互不影响。需要注意的是，子线程创建后，父线程中对局部变量的修改，子线程是无法感知的。这点需要注意，接下来是使用示例：

public class InheritableThreadLocalDemo {

    private static InheritableThreadLocal<String> threadLocal = new InheritableThreadLocal<>();

    public static void main(String[] args) {
        threadLocal.set("mainThread");
        System.out.println("value:"+threadLocal.get());
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                String value = threadLocal.get();
                System.out.println("value:"+value);
            }
        });
        thread.start();
    }
}

执行结果：

value:mainThread
value:mainThread

如果将上述代码中 InheritableThreadLocal 改成 ThreadLocal, 则子线程中输出的值为 null

public class InheritableThreadLocalDemo {

    private static ThreadLocal<String> threadLocal = new ThreadLocal<>();

    public static void main(String[] args) {
        threadLocal.set("mainThread");
        System.out.println("value:"+threadLocal.get());
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                String value = threadLocal.get();
                System.out.println("value:"+value);
            }
        });
        thread.start();
    }
}

执行结果：

value:mainThread
value:null

潜在的问题

ThreadLocal 虽然带来了很多的便利，但是使用不当的话，会导致内存泄漏，尤其是在 Thread 生命周期特别长情况下，比如线程池中的线程。如果当前线程不需要 ThreadLocal 后，应该使用 ThreadLocal 的 remove() 方法手动删除 ThreadLocal 存储的数据。

在哪些场景下使用

非线程安全的对象：Java 中的很多类都是非线程安全的，例如 SimpleDateFormat，NumberFormat. 通过 ThreadLocal 来使用这些类，可以让每个线程都拥有它们自己的实例，从而避免并发相关的问题。
线程特定上下文数据：需要在应用程序的不同层(方法)中访问的数据可以使用 ThreadLocal，比如用户信息，国际化设置或者是其他的上下文信息。这样可以避免上下文数据通过方法参数的方式到处传递，提升代码的可维护性。

Websocket 教程

Wed, 02 Jul 2025 14:37:03 +0800

引言

在 Web2.0 时代，用户越来越期望 Web 应用的实时交互功能，而传统的 Web 技术实现起来会比较繁琐且浪费资源。因此在 2011 年的时候，IETF 发布了 WebScoket 协议标准，该协议允许客户端和服务端实时交互和双向沟通。

这篇博客将介绍什么是 WebSocket，WebSocket 是如何工作的。

背景

传统的 Web 应用程序依赖于 HTTP 的请求响应模型：客户端发送一次 HTTP 请求，然后等待服务器的响应。这种方式在大多数的场景下都没有问题，但是对于实时性要求比较高的场景，比如实时更新(比赛分数)，直播弹幕，在线聊天，请求响应模型只能够实现一个伪实时系统，且非常的浪费资源。为什么这么说呢？

请求响应模型要实时获取服务器中最新的消息，只能够通过长轮询(long polling)的方式来实现，但是长轮询的方式非常的消耗资源，多次 HTTP 请求，只有一次请求是有效的，其他的请求都是无效的，这种方式既消耗资源，效率又不高。同时请求响应模型实现起来需要在实时性和浪费资源这两个方面进行取舍。要想实时性高，就得加快轮询的频率，这也就意味着无效请求大量增加；要想节省资源，就得降低轮询频率，这就导致实时性变低。

而 WebSocket 就非常好的解决了请求响应模型的问题。

什么是 WebSocket

WebSocket 是建立在 TCP 长连接上的一个全双工应用层协议:

TCP 长连接：意味着免去了请求响应模型中重复打开和关闭 TCP 连接的开销。
全双工：意味着通信的双方可以同时发送和接受信息，互不干扰。

WebSocket 的工作原理

客户端通过 HTTP 向服务器发送将协议切换成 WebSocket 的握手请求。如果服务器支持 WebSocket 协议，就会在同一个 TCP 上将 HTTP 协议切换成 WebSocket 协议。升级的过程如下：

客户端向服务器发送带有指定请求头的 GET 请求，请求示例：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://example.com

比较重要的请求头：

Upgrade: websocket: 表示客户端想要升级成 WebSocket 协议
Connection: Upgrade: 表示该请求是一个想要升级连接的请求
Sec-WebSocket-Key: 客户端生成的 base64 编码随机值，用于服务器生成响应和验证握手
Sec-WebSocket-Version: 客户端所支持的 WebSocket 协议版本，通常是 13。如果服务端不支持该版本，需要返回一个Sec-WebSocket-Versionheader，用于告知客户端服务端支持的 WeSocket 版本。
Origin: 告诉服务器请求来源于哪个网站，非必须字段，基于安全方面的考虑，强烈推荐带上该请求头。服务端可通过白名单机制来决定是否要应答此次握手。

服务端验证以及接受升级

如果服务器接受升级，服务器需要将响应码设置成 101，并返回指定的一些字段：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

比较重要的字段：

101 Switching Protocols: 表示同意切换协议
Upgrade: websocket: 确认切换的协议为：websocket
Connection: Upgrade: 确认升级连接
Sec-WebSocket-Accept: 该字段的值由服务器基于请求的 Sec-WebSocket-Key 字段生成。服务端将 Sec-WebSocket-Key 字段的值与一个 GUID 进行拼接，并使用 SHA-1 算法进行 hash 计算，最后将 hash 值使用 Base64 算法进行编码

TCP 连接保持打开

WebSocket 的 URL 以 ws:// 或 wss:// 开头，其他的都与 http:// 和 https:// 类似。

ws:// 明文进行传输
was:// 基于 TSL/SSL 进行密文传输

WebSocket 使用场景

实时聊天应用
在线游戏
多人协同应用
金融交易平台
……

搭建 WebSocket 服务器

引入依赖

在 pom.xml 文件中新增 websocket 的依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
</dependency>

具体代码

WebSocketConfig.java

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.socket.server.standard.ServerEndpointExporter;

@Configuration
public class WebSocketConfig {

    @Bean
    public ServerEndpointExporter serverEndpointExporter() {
        return new ServerEndpointExporter();
    }

}

WebSocketServerConfig.java

import com.alibaba.nacos.common.utils.CollectionUtils;
import org.springframework.stereotype.Component;

import javax.websocket.HandshakeResponse;
import javax.websocket.server.HandshakeRequest;
import javax.websocket.server.ServerEndpointConfig;
import java.util.List;
import java.util.Map;

@Component
public class WebSocketServerConfig extends ServerEndpointConfig.Configurator {

    @Override
    public boolean checkOrigin(String originHeaderValue) {
        return true;
    }

    @Override
    public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest request, HandshakeResponse response) {
        Map<String, List<String>> parameterMap = request.getParameterMap();
        List<String> erpList = parameterMap.get("erp");
        if(!CollectionUtils.isEmpty(erpList)){
            sec.getUserProperties().put("erp", erpList.get(0));
        }
    }

}

ChickenSocket.java

import com.autmaple.circle.server.config.websocket.WebSocketServerConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;

import javax.websocket.EndpointConfig;
import javax.websocket.OnClose;
import javax.websocket.OnError;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
import java.io.IOException;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;

@Slf4j
@ServerEndpoint(value = "/chicken/socket", configurator = WebSocketServerConfig.class)
@Component
public class ChickenSocket {

    /**
     * 记录当前在线连接数
     */
    private static final AtomicInteger onlineCount = new AtomicInteger(0);

    /**
     * 存放所有在线的客户端
     */
    private static final Map<String, ChickenSocket> clients = new ConcurrentHashMap<>();

    /**
     * 与某个客户端的连接会话，需要通过它来给客户端发送数据
     */
    private Session session;

    /**
     * erp唯一标识
     */
    private String erp = "";

    public Session getSession() {
        return session;
    }

    /**
     * 连接建立成功调用的方法
     */
    @OnOpen
    public void onOpen(Session session, EndpointConfig conf) throws IOException {
        //获取用户信息
        try {
            Map<String, Object> userProperties = conf.getUserProperties();
            String erp = (String) userProperties.get("erp");
            this.erp = erp;
            this.session = session;
            if (clients.containsKey(this.erp)) {
                clients.get(this.erp).session.close();
                clients.remove(this.erp);
                onlineCount.decrementAndGet();
            }
            clients.put(this.erp, this);
            onlineCount.incrementAndGet();
            log.info("有新连接加入：{}，当前在线人数为：{}", erp, onlineCount.get());
            sendMessage("连接成功", this.session);
        } catch (Exception e) {
            log.error("建立链接错误{}", e.getMessage(), e);
        }
    }

    /**
     * 连接关闭调用的方法
     */
    @OnClose
    public void onClose() {
        try {
            if (clients.containsKey(erp)) {
                clients.get(erp).session.close();
                clients.remove(erp);
                onlineCount.decrementAndGet();
            }
            log.info("有一连接关闭：{}，当前在线人数为：{}", this.erp, onlineCount.get());
        } catch (Exception e) {
            log.error("连接关闭错误，错误原因{}", e.getMessage(), e);
        }
    }

    /**
     * 收到客户端消息后调用的方法
     */
    @OnMessage
    public void onMessage(String message, Session session) {
        log.info("服务端收到客户端[{}]的消息:{}", this.erp, message);
        //心跳机制
        if (message.equals("ping")) {
            this.sendMessage("pong", session);
        }
    }

    @OnError
    public void onError(Session session, Throwable error) {
        log.error("Socket:{},发生错误,错误原因{}", erp, error.getMessage(), error);
        try {
            session.close();
        } catch (Exception e) {
            log.error("onError.Exception{}", e.getMessage(), e);
        }
    }

    /**
     * 指定发送消息
     */
    public void sendMessage(String message, Session session) {
        log.info("服务端给客户端[{}]发送消息{}", this.erp, message);
        try {
            session.getBasicRemote().sendText(message);
        } catch (IOException e) {
            log.error("{}发送消息发生异常，异常原因{}", this.erp, message);
        }
    }

    /**
     * 群发消息
     */
    public void sendMessage(String message) {
        for (Map.Entry<String, ChickenSocket> sessionEntry : clients.entrySet()) {
            String erp = sessionEntry.getKey();
            ChickenSocket socket = sessionEntry.getValue();
            Session session = socket.session;
            log.info("服务端给客户端[{}]发送消息{}", erp, message);
            try {
                session.getBasicRemote().sendText(message);
            } catch (IOException e) {
                log.error("{}发送消息发生异常，异常原因{}", this.erp, message);
            }
        }
    }

    public ChickenSocket getChickenSocket(String userName) {
        return clients.get(userName);
    }
}

客户端的使用

var ws = new WebSocket("ws://docker.local.com/chicken/socket");

ws.onopen = function(event) { 
  console.log("Connection open ..."); 
  ws.send("Hello WebSockets!");
};

ws.onmessage = function(event) {
  console.log( "Received Message: " + event.data);
  ws.close();
};

ws.onclose = function(event) {
  console.log("Connection closed.");
};