小菜鸟

Java 并发同步工具：从信号量到交换器的全面解析

在多线程编程中，除了 synchronized 和 Lock 等基础同步机制，JUC（java.util.concurrent）包还提供了多种高级同步工具，用于解决复杂的线程协作问题。本文将详细介绍 信号量（Semaphore）、闭锁（CountDownLatch）、屏障（CyclicBarrier）、移相器（Phaser）和交换器（Exchanger） 的原理、用法及适用场景。

信号量（Semaphore）：控制并发访问数量

Semaphore 用于控制同时访问某一资源的线程数量，通过维护一个许可计数器实现。线程需要先获取许可（acquire()），访问完成后释放许可（release()）。

核心原理

• 许可计数器：初始化时指定许可数量（如 new Semaphore(5) 允许 5 个线程同时访问）；
• 获取与释放：acquire() 减少许可数（无许可时阻塞），release() 增加许可数；
• 公平性：支持公平模式（按请求顺序分配许可）和非公平模式（默认，允许插队）。

源码关键方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 获取 1 个许可（可中断）  
public void acquire() throws InterruptedException {  
    sync.acquireSharedInterruptibly(1);  
}  

// 释放 1 个许可  
public void release() {  
    sync.releaseShared(1);  
}  

// 尝试获取许可（非阻塞）  
public boolean tryAcquire() {  
    return sync.nonfairTryAcquireShared(1) >= 0;  
}  

典型应用：限流

Tomcat 性能优化全指南

Tomcat 作为主流的 Java Web 容器，其性能直接影响应用的响应速度和并发能力。通过合理配置线程池、连接器、JVM 参数等，可以显著提升 Tomcat 的处理能力。本文将从执行器调优、连接器配置、JVM 优化等多个维度，详细介绍 Tomcat 性能优化的核心策略。

执行器（线程池）调优

Tomcat 的线程池（Executor）是处理请求的核心组件，负责管理请求处理线程。合理配置线程池参数可以避免线程频繁创建 / 销毁的开销，提升并发处理能力。

核心配置参数

1
2
3
4
5
6
7
8
9

<Executor 
  name="tomcatThreadPool"        <!-- 线程池名称（唯一标识） -->
  namePrefix="catalina-exec-"    <!-- 线程名称前缀（便于日志排查） -->
  maxThreads="500"               <!-- 最大线程数（并发处理的核心参数） -->
  minSpareThreads="50"           <!-- 最小空闲线程数（启动时初始化的线程数） -->
  maxIdleTime="60000"            <!-- 线程空闲超时时间（毫秒，默认 60000） -->
  maxQueueSize="1000"            <!-- 任务队列最大长度（超出则拒绝请求） -->
  prestartminSpareThreads="true" <!-- 启动时是否初始化 minSpareThreads 个线程 -->
/>

参数调优建议

• maxThreads：
  决定并发处理的上限，需根据服务器 CPU 核心数调整。建议：
  • 4 核 CPU：设置为 200-400
  • 8 核 CPU：设置为 400-800
    过高会导致线程切换开销增大，反而降低性能。
• minSpareThreads：
  避免请求突增时频繁创建线程，建议设置为 maxThreads 的 1/10~1/5（如 500 线程池对应 50-100）。
• maxQueueSize：
  当线程全部繁忙时，请求会进入队列等待。建议设置为 maxThreads 的 2-3 倍（如 500 线程对应 1000-1500），过大可能导致请求超时。
• prestartminSpareThreads：
  生产环境建议设为 true，启动时初始化核心线程，避免首笔请求的线程创建开销。

启用线程池

配置后需在 Connector 中引用，否则不会生效：

Kafka 日志管理器详解：存储、索引与清理机制

Kafka 的日志管理器（Log Manager）是数据持久化的核心组件，负责消息的存储、检索、维护和清理，直接影响 Kafka 的性能、可靠性和磁盘占用。本文将从日志存储结构、索引机制、检索流程到日志清理策略，全面解析日志管理器的工作原理。

日志存储基础

Kafka 中的 “日志” 并非传统意义上的文本日志，而是消息的持久化存储结构。其设计目标是高效支持高吞吐的写入和随机读取，核心特点是 “顺序写、分段存储”。

存储结构概览

• 主题与分区映射：每个主题（Topic）的每个分区（Partition）对应一个独立的日志目录，命名格式为 {topic}-{partition}（如 test-topic-0、test-topic-1）。
• 副本存储：分区的每个副本（Replica）在不同 Broker 上拥有独立的日志目录，确保数据冗余。
• 日志文件组织：每个日志目录包含多个日志段（LogSegment），每个 LogSegment 由 3 个文件组成：
  • .log：存储消息的实际内容（二进制格式）。
  • .index：偏移量索引文件，映射消息偏移量到 .log 文件中的物理位置。
  • .timeindex：时间戳索引文件，映射消息时间戳到偏移量。

日志分段（LogSegment）

Kafka 将每个分区的日志拆分为多个 LogSegment（默认最大 1GB），而非一个巨大的文件，原因如下：

• 便于管理：单个大文件难以高效定位和删除，分段后可按段操作（如删除老数据）。
• 提升性能：索引文件随分段变小，可缓存至内存，加速查询。
• 并行处理：分段操作可分布式进行，避免单文件锁竞争。

日志文件的名称是以偏移量进行命名的，这样是为了方便知道数据在哪个日志段中(采用了跳跃表的方式)

在Log对象中维护了一个ConcurrentSkipListMap(底层是跳跃表)，保存该主题所有分区对应的所有LogSegment

1
2

/* the actual segments of the log */
private val segments: ConcurrentNavigableMap[java.lang.Long, LogSegment] = new ConcurrentSkipListMap[java.lang.Long, LogSegment]

LogSegment中封装有一个FileRecords对象(日志文件)，一个OffsetIndex对象(偏移量索引文件)和一个TimeIndex对象(时间戳索引文件)

1
2
3
4
5
6
7
8

class LogSegment private[log] (val log: FileRecords,
                               val offsetIndex: OffsetIndex,
                               val timeIndex: TimeIndex,
                               val txnIndex: TransactionIndex,
                               val baseOffset: Long,
                               val indexIntervalBytes: Int,
                               val rollJitterMs: Long,
                               val time: Time) extends Logging 

在存储结构上每个分区副本对应一个目录，每个分区副本由一个或多个日志段(LogSegment)组成。每个日志段在物理结构上对应一个以.index后缀的偏移量索引文件、一个以.timeindex后缀的时间戳索引文件和一个以.log结尾的日志文件

使用.index后缀的偏移量索引文件是为了方便定位数据，在.index文件中记录了许多偏移量的索引，每隔一个范围区间创建一个索引，这种方式称之为稀疏索引。这样可以避免索引文件过大，从而使得内存中可以保存更多的索引

使用.timeindex文件是为了kafka清理数据准备的，kafka默认是保留七天内的数据的，主要根据timeindex时间索引文件里最大的时间来判断的，如果最大时间与当前时间差值超过7天，那么对应的数据段就会被清理掉

关键配置：

• log.segment.bytes：单个 LogSegment 的最大大小（默认 1073741824 字节，即 1GB）。
• log.roll.ms/log.roll.hours：LogSegment 滚动周期（即使未达大小上限，超时也会创建新段，默认 7 天）。

日志文件与索引机制

1. 日志文件（.log）

.log 文件是消息的实际存储载体，消息以追加（Append） 方式写入（顺序写磁盘，性能远高于随机写）。每条消息包含以下核心字段：

Kafka 网络通信机制详解：从连接到请求处理的全流程

Kafka 的高性能很大程度上依赖于其高效的网络通信模型。Kafka 基于 Java NIO 实现了一套分层的线程模型，通过 SocketServer 组件协调连接接收、请求处理和响应发送，支撑了高并发、低延迟的消息传输。本文将深入解析 Kafka 网络通信的核心组件（Acceptor、Processor、RequestChannel、KafkaRequestHandler）及其协作流程。

网络通信模型总览

Kafka 的网络通信采用 “分层分离” 的设计思想，将连接管理、IO 操作和业务处理解耦，核心线程模型分为三层：

1. Acceptor 线程：负责接收客户端新连接，通过轮询策略分配给 Processor。
2. Processor 线程：处理连接的读写事件，将请求放入缓冲队列，并负责发送响应。
3. KafkaRequestHandler 线程：从缓冲队列中获取请求，通过业务逻辑处理后生成响应。

三者通过 RequestChannel 实现通信，形成 “接收→缓冲→处理→响应” 的完整流程。这种设计充分利用了 NIO 的非阻塞特性，避免了传统阻塞 IO 的性能瓶颈，支持高并发请求处理。

核心组件详解

Acceptor：连接接收者

Acceptor 是 Kafka 网络通信的 “入口”，负责监听客户端的新连接请求，其核心职责是接收连接并分发到 Processor，实现负载均衡。

工作原理：

• 单线程监听：Acceptor 是一个独立线程，通过 ServerSocketChannel 监听指定端口（如 9092），注册 SelectionKey.OP_ACCEPT 事件（接收连接事件）。
• 轮询分配连接：当新连接到来时，Acceptor 接收连接（SocketChannel），并通过轮询策略将其分配给某个 Processor（避免单个 Processor 负载过高）。
• 无业务处理：Acceptor 仅负责连接分发，不参与请求读写，最大限度减少自身开销。

核心代码与逻辑：

Web 应用部署核心：web.xml 配置文件详解

web.xml 是 Java Web 应用的核心部署描述文件，用于定义应用的初始化参数、Servlet 映射、过滤器、安全约束等配置。它分为两个层级：Tomcat 全局默认配置（conf/web.xml）和应用自定义配置（WEB-INF/web.xml），后者会覆盖前者的同名配置。本文将系统解析 web.xml 的核心配置项及用法。

配置文件结构概览

web.xml 的配置项按功能可分为以下类别，本文将逐一详解：

1. ServletContext 初始化参数
2. 会话配置（Session）
3. Servlet 声明与映射
4. 生命周期监听器（Listener）
5. 过滤器（Filter）定义与映射
6. MIME 类型映射
7. 欢迎文件列表
8. 错误页面配置
9. 本地化与编码映射
10. 安全配置
11. JNDI 资源配置

核心配置项详解

1. ServletContext 初始化参数

通过 <context-param> 定义全局参数，所有 Servlet 和过滤器可通过 ServletContext.getInitParameter() 获取。适用于存储应用级常量（如版本号、配置路径）。

配置示例：

1
2
3
4
5
6
7
8

<context-param>
  <param-name>app.version</param-name>
  <param-value>1.0.0</param-value>
</context-param>
<context-param>
  <param-name>api.endpoint</param-name>
  <param-value>https://api.example.com</param-value>
</context-param>

获取方式：

1
2

// 在 Servlet 中
String version = getServletContext().getInitParameter("app.version");

2. 会话配置（<session-config>）

用于配置 HTTP 会话的全局属性，包括超时时间、Cookie 策略、会话追踪模式等。

配置示例：