建设营销型网站的步骤,seo刷词,建设银行的网站,网上推广网站目录 1.高级并发模式
1.1 工作窃取#xff08;Work Stealing#xff09;
1.工作窃取模式
2.ForkJoinPool实现
3.具体例子
1.2 结构化并发#xff08;Structured Concurrency#xff09;
1.结构化并发模式
2.Java 19 的 StructuredTaskScope
3.具体例子 1.3 对比与…目录 1.高级并发模式
1.1 工作窃取Work Stealing
1.工作窃取模式
2.ForkJoinPool实现
3.具体例子
1.2 结构化并发Structured Concurrency
1.结构化并发模式
2.Java 19 的 StructuredTaskScope
3.具体例子 1.3 对比与总结
1.工作窃取Work Stealing
2.结构化并发Structured Concurrency
2.性能瓶颈突破方案
2.1 锁优化对比表
1. 计数器累加
1.1 传统方案synchronized
1.2 优化方案LongAdder
1.3 性能提升
1.4 分段锁与无锁编程技术
1. 分段锁Segmented Lock
1.1 举例说明
1.2优点
2. 无锁编程Lock-Free Programming(自旋锁)
2.1 优点不存在死锁
2.2 缺点
2.3潜在问题与优化方向
2.4 场景
3.分段锁与无锁编程的区别
4.总结
1.5 并发数据结构
1. 并发List
1.1 CopyOnWriteArrayList 的 写时复制 机制解析
2. 并发Set 3. 并发Map
3.1 跳表Skip List数据结构基础
3.2 ConcurrentSkipListMap 的并发控制机制
4.并发Queue
4.1 ArrayBlockingQueue
4.2 生产者 - 消费者模型的典型应用
4.3 模型优势
4.4 与其他阻塞队列的对比
4.5 使用场景与注意事项
4.6 核心源码逻辑简析
4.7 LinkedBlockingQueue
4.8 读写分离锁
4.9 链表结构
5.日志处理场景
5.1 实现日志处理的步骤
5.2 消息队列的本地缓冲与日志系统的缓冲
5.3 是否需要额外的缓冲层
5.4 常见的日志系统
5.5 示例使用 LinkedBlockingQueue 作为日志缓冲
5.6 总结
5.7 日志写很需要毕竟要记录为什么说他的读也很频繁呢
5.8 存储引擎优化
5.9 Redis和ZooKeeper对比 6. 设计思想对比 7. 选型建议
2. 对象池
2.1 传统方案ReentrantLock
2.2 优化方案StampedLock 乐观读
2.3 乐观锁
1.乐观锁的工作原理
2.乐观锁的实现方式
2.1 基于版本号Version Number
2.2 基于时间戳Timestamp
2.3 乐观锁的优点
2.4 乐观锁的缺点
2.5 适用场景
2.6 示例代码
2.7 总结
3. 缓存更新
3.1 传统方案全局锁
3.2 优化方案ConcurrentHashMap 分段
3.3 性能提升
2.2 伪共享False Sharing解决
1.什么是伪共享
2 伪共享的危害
3 伪共享实例解析
4 解决方案缓存行填充
5.Java 8 中的 Contended 注解
6.性能对比测试
7.实际应用场景
8.何时需要关注伪共享
9.总结 1.高级并发模式
1.1 工作窃取Work Stealing
1.工作窃取模式
工作窃取是一种并发编程模式用于在多线程环境中高效地分配任务。其核心思想是 每个线程都有自己的任务队列。 当一个线程完成自己的任务后它会从其他线程的任务队列中“窃取”任务来执行。 这种模式可以有效减少线程的空闲时间提高整体的并发效率。
2.ForkJoinPool实现
ForkJoinPool是Java中实现工作窃取模式的工具类。它通过分治法将大任务分解为多个小任务并在多个线程中并行执行。
3.具体例子
以下是一个使用ForkJoinPool实现工作窃取的例子
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ForkJoinPool;
import java.util.stream.Collectors;
import java.util.stream.IntStream;public class WorkStealingExample {public static void main(String[] args) {// 创建一个ForkJoinPool指定线程数为4ForkJoinPool pool new ForkJoinPool(4);// 提交任务到ForkJoinPoolpool.submit(() - {// 创建100个异步任务ListCompletableFutureVoid tasks IntStream.range(0, 100).mapToObj(i - CompletableFuture.runAsync(() - process(i), pool)).collect(Collectors.toList());// 等待所有任务完成CompletableFuture.allOf(tasks.toArray(new CompletableFuture[0])).join();});// 关闭线程池pool.shutdown();}// 模拟任务处理逻辑private static void process(int i) {System.out.println(处理任务: i 线程: Thread.currentThread().getName());try {Thread.sleep(100); // 模拟耗时操作} catch (InterruptedException e) {e.printStackTrace();}}
}关键点
ForkJoinPool用于管理线程池和任务队列。
CompletableFuture.runAsync用于创建异步任务并指定线程池。
CompletableFuture.allOf用于等待多个异步任务完成。
1.2 结构化并发Structured Concurrency
1.结构化并发模式
结构化并发是一种新的并发编程模式旨在简化并发任务的管理。其核心思想是 将并发任务的生命周期限制在特定的作用域内。 通过try-with-resources语法自动管理任务的启动和关闭。 提供统一的异常处理机制。
2.Java 19 的 StructuredTaskScope
Java 19引入了StructuredTaskScope用于实现结构化并发。它提供了以下功能 fork启动一个子任务。 join等待所有子任务完成。 throwIfFailed检查是否有子任务失败并抛出异常。
3.具体例子
以下是一个使用StructuredTaskScope实现结构化并发的例子
import java.util.concurrent.StructuredTaskScope;
import java.util.concurrent.Future;public class StructuredConcurrencyExample {public static void main(String[] args) {try (var scope new StructuredTaskScope.ShutdownOnFailure()) {// 启动两个子任务FutureString user scope.fork(() - fetchUser());FutureInteger order scope.fork(() - fetchOrder());// 等待所有子任务完成scope.join();// 检查是否有子任务失败scope.throwIfFailed();// 获取子任务的结果String userName user.resultNow();Integer orderCount order.resultNow();// 返回最终结果System.out.println(用户: userName , 订单数量: orderCount);} catch (Exception e) {e.printStackTrace();}}// 模拟获取用户信息private static String fetchUser() {System.out.println(获取用户信息线程: Thread.currentThread().getName());try {Thread.sleep(1000); // 模拟耗时操作} catch (InterruptedException e) {e.printStackTrace();}return Alice;}// 模拟获取订单信息private static Integer fetchOrder() {System.out.println(获取订单信息线程: Thread.currentThread().getName());try {Thread.sleep(1000); // 模拟耗时操作} catch (InterruptedException e) {e.printStackTrace();}return 5;}
}关键点
StructuredTaskScope用于管理并发任务的作用域。fork启动一个子任务。join等待所有子任务完成。throwIfFailed检查是否有子任务失败并抛出异常。resultNow获取子任务的结果。 1.3 对比与总结
1.工作窃取Work Stealing 优点 高效利用线程资源减少线程空闲时间。 适用于任务数量较多且任务大小不均匀的场景。 缺点 需要手动管理线程池和任务队列。 异步任务的生命周期管理较为复杂。
2.结构化并发Structured Concurrency 优点 简化并发任务的生命周期管理。 提供统一的异常处理机制。 代码更加清晰易读。 缺点 需要Java 19及以上版本支持。 适用场景较为有限主要用于并发任务较少且生命周期较短的场景。
通过使用这两种高级并发模式可以更好地管理并发任务提高系统的性能和可维护性。
2.性能瓶颈突破方案
2.1 锁优化对比表 1. 计数器累加
1.1 传统方案synchronized
使用 synchronized 同步方法或代码块来保护计数器的累加操作。
public class Counter {private long value 0;public synchronized void increment() {value;}public synchronized long getValue() {return value;}
}
1.2 优化方案LongAdder
LongAdder 是 Java 8 引入的一个高性能的计数器适用于高并发场景。
import java.util.concurrent.atomic.LongAdder;public class Counter {private final LongAdder value new LongAdder();public void increment() {value.increment();}public long getValue() {return value.sum();}
} 1.3 性能提升 传统方案synchronized 是一种重量级的同步机制会导致线程阻塞和上下文切换。 优化方案LongAdder 使用了分段锁和无锁编程技术性能提升约 8 倍。 1.4 分段锁与无锁编程技术
1. 分段锁Segmented Lock
分段锁是一种将共享数据划分为多个段并为每个段分配独立锁的机制。通过这种方式多个线程可以同时访问不同的数据段从而减少锁的竞争提高并发性能。
1.1 举例说明
以下是一个简单的分段锁实现示例使用ReentrantLock作为锁机制并假设我们正在处理一个整数数组该数组被划分为多个段。 SuppressWarnings(unchecked)public SegmentedLock(int size, int segments) {this.segments segments;this.data (T[]) new Object[size]; // 创建泛型数组this.locks new ReentrantLock[segments];// 初始化每个段的锁for (int i 0; i segments; i) {locks[i] new ReentrantLock();}}// 计算索引对应的段号private int segmentIndex(int index) {return index % segments;}// 安全地访问数据public void setData(int index, T value) {int segment segmentIndex(index);locks[segment].lock();try {data[index] value;} finally {locks[segment].unlock();}}public T getData(int index) {int segment segmentIndex(index);locks[segment].lock();try {return data[index];} finally {locks[segment].unlock();}}
}核心设计思路
分段策略
将数据数组分成固定数量的段 (segments)
每个段拥有独立的锁不同段的操作可以并行执行
当线程访问某个索引位置时只需要获取该索引对应的段锁
锁粒度控制
通过调整segments参数可以控制锁的粒度
段数越多并发度越高但内存开销也越大
段数太少可能导致锁竞争激烈性能下降
索引到段的映射
使用取模运算 (index % segments) 将索引映射到对应的段
这种简单的映射方式保证了分布均匀性但可能导致热点问题关键方法解析
构造函数
接收数据数组大小和段数作为参数
初始化数据数组和锁数组
为每个段创建独立的ReentrantLock实例segmentIndex 方法
使用取模运算将数组索引映射到对应的段
例如当段数为 4 时索引 0-3 对应段 04-7 对应段 1依此类推
setData 和 getData 方法获取索引对应的段锁
在锁的保护下执行读写操作
使用 try-finally 确保锁一定会被释放优势与应用场景
性能优势
相比全局锁分段锁可以显著提高并发性能
假设段数为 16理想情况下可以支持 16 倍的并发吞吐量
适用场景
高并发的哈希表实现 (如 ConcurrentHashMap 的早期版本)
分布式缓存系统
高性能队列和栈
其他需要频繁读写共享数据的场景
与读写锁的对比
分段锁适用于写操作较多的场景
读写锁适用于读多写少的场景潜在问题与优化方向热点问题
如果某些段被频繁访问可能导致这些段的锁竞争激烈
可以考虑使用更复杂的 哈希函数 来分散热点段数选择
段数应根据系统核心数和预期并发量来调整
一般建议段数为 CPU 核心数的 2-4 倍锁升级
如果需要对整个数据结构进行操作可以实现获取所有段锁的方法
但要注意避免死锁问题使用读写锁
对于读多写少的场景可以将ReentrantLock替换为ReentrantReadWriteLock
通过这种分段锁设计可以在保证线程安全的同时最大限度地提高并发性能特别适合需要频繁读写共享数据的高并发场景。1.2优点 减少了锁的竞争提高了并发性能。 适用于频繁读、写操作的场景。
缺点 实现复杂度较高维护成本增加。 如果分段数量设置不当可能会导致热点分段出现性能瓶颈。
2. 无锁编程Lock-Free Programming(自旋锁)
无锁编程是一种不依赖于传统锁机制的并发编程技术。它通过原子操作如Compare-And-SwapCAS来实现线程间的协调从而避免了锁的使用。
举例说明 以下是一个使用CAS操作的无锁编程示例实现了一个简单的线程安全的计数器。
import java.util.concurrent.atomic.AtomicInteger;public class LockFreeCounter {private AtomicInteger counter new AtomicInteger(0);public void increment() {while (true) {int currentValue counter.get();int newValue currentValue 1;if (counter.compareAndSet(currentValue, newValue)) {break;}// 如果CAS失败循环会自动重试}}public int get() {return counter.get();}
}无锁计数器的核心是 CASCompare-And-Swap 操作
CAS 是一种原子操作包含三个参数内存位置 (V)、预期原值 (A) 和新值 (B)
仅当 V 的值等于 A 时才将 V 的值更新为 B否则不执行任何操作
CAS 操作是原子的由 CPU 指令直接支持不会被中断在这个实现中
获取当前计数器值
计算新值当前值 1
使用 CAS 尝试更新计数器
如果更新失败说明有其他线程修改了值则重试关键方法解析
构造函数
初始化一个 AtomicInteger初始值为 0
AtomicInteger 提供了原子操作的能力increment 方法
获取当前值
计算新值1使用 compareAndSet 尝试更新
如果当前值仍然是获取时的值则更新成功
如果其他线程已经修改了值则更新失败循环会重试这种模式称为 CAS 循环或自旋锁get 方法
原子性地获取当前计数器值
不需要额外的同步因为 AtomicInteger 的 get 方法是线程安全的2.1 优点不存在死锁 性能优势 无锁操作避免了线程阻塞和上下文切换在高并发环境下通常比基于锁的实现性能更好特别适合计数器、ID 生成器等场景 线程安全 保证了操作的原子性和可见性多个线程可以同时尝试递增不会出现数据竞争
2.2 缺点 实现复杂需要深入理解原子操作和内存模型。 在某些情况下可能会遇到ABA问题。 ABA问题发生在多线程环境中当一个线程读取一个共享变量的值为A在它进行操作之前被挂起另一个线程将该值改为B然后再改回A。当第一个线程恢复执行时由于CAS操作只检查值是否未变不关心值的变化历史因此会继续执行操作导致逻辑错误 2.3潜在问题与优化方向 ABA 问题 如果值从 A 变为 B 再变回 ACAS 会认为值没有变化在这个计数器场景中不会有问题因为值总是递增的对于更复杂的场景可以使用 AtomicStampedReference 解决 自旋消耗 CPU 在高度竞争的情况下线程可能频繁重试 CAS可以考虑使用 LongAdderJDK 8 引入它在高竞争下性能更好 可扩展性 这个实现是单变量的不支持批量操作对于需要批量操作的场景可以考虑使用锁或其他并发数据结构
2.4 场景
计数器、统计器分布式系统中的 ID 生成器高性能队列的索引指针任何需要高效并发递增的场景
3.分段锁与无锁编程的区别 锁机制分段锁依赖于传统锁机制通过将锁的粒度细化来减少竞争无锁编程则完全不使用锁而是通过原子操作来实现线程间的协调。 性能无锁编程在某些场景下可以提供更高的性能因为它避免了锁的开销分段锁则在数据访问模式较为分散时表现较好。 实现复杂度无锁编程的实现通常更为复杂需要对原子操作和内存模型有深入的理解分段锁的实现相对简单但维护成本较高。 4.总结
分段锁和无锁编程都是用于提高并发性能的技术。分段锁通过将锁的粒度细化来减少竞争适用于读操作频繁的场景无锁编程则通过原子操作避免了锁的使用适用于对性能要求极高的场景。选择哪种技术取决于具体的应用场景和性能需求。 1.5 并发数据结构
涵盖List、Set、Map、Queue等类型
1. 并发List 1.1 CopyOnWriteArrayList 的 写时复制 机制解析 写时复制(Copy-On-Write, COW) 是一种重要的内存管理和并发控制技术在CopyOnWriteArrayList中得到了典型应用。这种机制的核心思想是当需要修改数据时不直接修改原数据而是先复制一份在副本上进行修改修改完成后再用副本替换原数据。 1.写时复制的工作原理
在CopyOnWriteArrayList中 读操作 无需加锁直接访问底层数组读取的是操作开始时数组的快照不会阻塞其他读操作或写操作 写操作 需要获取独占锁ReentrantLock复制当前数组到一个新数组在新数组上进行修改添加、删除、更新元素用新数组替换原数组释放锁 数据一致性 提供弱一致性Weak Consistency读操作可能看不到最新的写操作结果但保证数据在读取时是完整的
2.代码实现示例
public class CopyOnWriteArrayListE {private transient volatile Object[] array;private final ReentrantLock lock new ReentrantLock();// 获取当前数组final Object[] getArray() {return array;}// 设置新数组final void setArray(Object[] a) {array a;}// 读操作无锁public E get(int index) {return elementAt(getArray(), index);}// 写操作加锁复制public boolean add(E e) {final ReentrantLock lock this.lock;lock.lock();try {Object[] elements getArray();int len elements.length;// 复制原数组到新数组长度1Object[] newElements Arrays.copyOf(elements, len 1);// 在新数组末尾添加元素newElements[len] e;// 用新数组替换原数组setArray(newElements);return true;} finally {lock.unlock();}}// 其他方法...
}
3.写时复制的优势 高并发读性能 读操作完全无锁性能接近数组适合读操作远多于写操作的场景 线程安全 写操作通过锁保证原子性读操作不会看到不完整的数据 简化并发控制 无需复杂的读写锁控制实现简单易于理解和维护
4. 写时复制的缺点 内存开销大 每次写操作都需要复制整个数组对于大数组或频繁写操作内存消耗显著 写操作性能低 涉及锁获取、数组复制和替换写操作性能远低于普通 ArrayList 数据弱一致性 读操作可能看不到最新的写操作结果不适合需要强一致性的场景 迭代器问题 迭代器创建时会复制当前数组迭代器不支持修改操作迭代过程中不会反映数组的修改 写时复制是一种以空间换时间的并发控制策略通过在写操作时复制数据结构避免了读写锁的开销实现了无锁的读操作。这种机制特别适合读操作远多于写操作且对内存使用不太敏感的场景。在设计高并发系统时合理选择并发集合是提高系统性能的关键之一。 5.适用场景 读多写少的场景 配置信息存储很少修改频繁读取事件监听器列表注册少触发多缓存系统写操作少读操作多 需要线程安全但不要求强一致性的场景 统计信息收集允许短暂的不一致配置变更通知不要求立即生效 需要在迭代过程中修改集合的场景 普通集合在迭代时修改会抛出 ConcurrentModificationExceptionCopyOnWriteArrayList 的迭代器不会受影响对写时复制的迭代器部分进行优化如下所说 CopyOnWriteArrayList的迭代器不会受到修改操作的影响是因为它在创建时获取了数组的一个快照并且在迭代过程中操作的是这个快照而不是原始数组。这种机制使得CopyOnWriteArrayList在多线程环境中非常安全但同时也带来了内存和性能的开销。因此CopyOnWriteArrayList适用于读多写少的场景。 2. 并发Set 3. 并发Map ConcurrentSkipListMap 是 Java 并发包中的一个重要组件它结合了跳表数据结构和并发控制机制提供了线程安全的有序映射功能。下面我将详细解析其工作原理、优势和适用场景。
3.1 跳表Skip List数据结构基础
跳表是一种随机化的数据结构它通过在每个节点中维护多个指向其他节点的指针形成多级索引结构从而达到快速查找的目的。 1.核心思想
在有序链表的基础上增加多级 快速通道每一级都是下一级的子集形成类似二分查找的结构插入、删除和查找操作的时间复杂度均为 O (log n)
2.跳表结构示例 3.实现
import java.util.Random;class SkipListNode {int value;SkipListNode[] next;public SkipListNode(int value, int level) {this.value value;this.next new SkipListNode[level];}
}class SkipList {private static final int MAX_LEVEL 16; // 最大层数private SkipListNode head; // 头节点private int currentLevel; // 当前跳表的层数private Random random new Random();public SkipList() {head new SkipListNode(Integer.MIN_VALUE, MAX_LEVEL);currentLevel 1;}// 随机生成一个层数private int randomLevel() {int level 1;while (random.nextDouble() 0.5 level MAX_LEVEL) {level;}return level;}// 插入一个值public void insert(int value) {SkipListNode[] update new SkipListNode[MAX_LEVEL]; // 存储每一层的插入位置SkipListNode current head; // 从头节点开始// 找到每一层的插入位置for (int i currentLevel - 1; i 0; i--) {while (current.next[i] ! null current.next[i].value value) {current current.next[i]; // 向右移动}update[i] current; // 保存当前层的插入位置}// 生成随机层数int level randomLevel();if (level currentLevel) { // 如果生成的层数大于当前层数for (int i currentLevel; i level; i) {update[i] head; // 多余的层指向头节点}currentLevel level; // 更新当前层数}// 创建新节点SkipListNode newNode new SkipListNode(value, level);// 插入新节点for (int i 0; i level; i) {newNode.next[i] update[i].next[i]; // 新节点的next指针指向update数组中对应层的next节点update[i].next[i] newNode; // update数组中对应层的next指针指向新节点}
}// 搜索一个值public boolean search(int value) {SkipListNode current head;for (int i currentLevel - 1; i 0; i--) {while (current.next[i] ! null current.next[i].value value) {current current.next[i];}}if (current.next[0] ! null current.next[0].value value) {return true;}return false;}// 删除一个值public void delete(int value) {SkipListNode[] update new SkipListNode[MAX_LEVEL];SkipListNode current head;// 找到每一层的删除位置for (int i currentLevel - 1; i 0; i--) {while (current.next[i] ! null current.next[i].value value) {current current.next[i];}update[i] current;}if (current.next[0] ! null current.next[0].value value) {for (int i 0; i currentLevel; i) {if (update[i].next[i] ! null update[i].next[i].value value) {update[i].next[i] update[i].next[i].next[i];}}}}// 打印跳表public void printList() {for (int i currentLevel - 1; i 0; i--) {SkipListNode current head.next[i];System.out.print(Level i : );while (current ! null) {System.out.print(current.value );current current.next[i];}System.out.println();}}
}public class SkipListExample {public static void main(String[] args) {SkipList skipList new SkipList();skipList.insert(3);skipList.insert(6);skipList.insert(7);skipList.insert(9);skipList.insert(12);System.out.println(跳表内容);skipList.printList();System.out.println(搜索 7: skipList.search(7)); // 应该返回 trueSystem.out.println(搜索 14: skipList.search(14)); // 应该返回 falseSystem.out.println(删除 7);skipList.delete(7);skipList.printList();}
}
3.2 ConcurrentSkipListMap 的并发控制机制
ConcurrentSkipListMap 采用了无锁Lock-Free算法实现并发控制 原子操作 使用 Unsafe 类的 CASCompare-And-Swap操作确保对节点的修改是原子的避免锁竞争 分段更新 只对需要修改的节点加锁不会阻塞整个数据结构 乐观锁策略 先尝试修改失败则重试减少锁的持有时间提高并发性能
1.核心特性与优势 有序性 键按照自然顺序或指定的比较器排序提供了 headMap、tailMap、subMap 等范围查询方法 线程安全 所有操作都是线程安全的无需外部同步机制 高效的范围查询 跳表结构非常适合范围查询时间复杂度为 O (log n m)其中 m 是结果集大小 无锁设计 相比 Collections.synchronizedSortedMap 或 TreeMap 加锁性能更高特别适合高并发环境 弱一致性迭代器 迭代器不会抛出 ConcurrentModificationException反映创建迭代器时的状态可能不反映最新修改
2.与其他并发映射的对比
特性ConcurrentSkipListMapConcurrentHashMapLinkedHashMap有序性是否是插入顺序或访问顺序并发控制无锁分段锁 / 无锁需外部同步范围查询高效不支持不支持查找复杂度O(log n)O(1)O(n)适用场景排序和范围查询高并发随机访问缓存淘汰策略
3.适用场景 需要排序的并发场景 排行榜系统如游戏分数排名时间序列数据按时间戳排序优先级队列 范围查询频繁的场景 区间查询如查询价格在 100-200 之间的商品分页查询获取指定范围内的数据 高并发环境 分布式系统中的配置中心实时监控系统的指标存储
4.代码示例
import java.util.concurrent.ConcurrentSkipListMap;public class ConcurrentSkipListMapExample {public static void main(String[] args) {// 创建ConcurrentSkipListMap键为Integer值为StringConcurrentSkipListMapInteger, String map new ConcurrentSkipListMap();// 并发添加元素Thread t1 new Thread(() - {for (int i 0; i 1000; i) {map.put(i, Value- i);}});Thread t2 new Thread(() - {for (int i 1000; i 2000; i) {map.put(i, Value- i);}});t1.start();t2.start();try {t1.join();t2.join();} catch (InterruptedException e) {e.printStackTrace();}// 范围查询示例System.out.println(所有键小于500的条目);map.headMap(500).forEach((k, v) - System.out.println(k : v));System.out.println(\n键在500到1500之间的条目);map.subMap(500, 1500).forEach((k, v) - System.out.println(k : v));System.out.println(\n第一个键 map.firstKey());System.out.println(最后一个键 map.lastKey());}
}5.性能优化建议 合理选择键类型 键的比较操作是性能关键对于自定义对象确保 compareTo 方法高效 避免频繁的插入和删除 跳表在频繁修改时需要重新平衡适合读多写少的场景 批量操作 使用 putAll 等批量操作方法减少 CAS 操作次数 监控内存使用 跳表需要额外的指针空间对于大数据集考虑内存使用
通过合理使用 ConcurrentSkipListMap可以在保证线程安全的同时高效地处理有序数据和范围查询特别适合需要高并发排序功能的场景。
4.并发Queue 4.1 ArrayBlockingQueue 是 Java 并发包java.util.concurrent中的一个有界阻塞队列基于数组实现具备以下核心特性 有界性创建时需指定容量上限无法动态扩容超出容量时插入操作会阻塞生产者等待。阻塞机制 当队列已满时put 方法会阻塞生产者线程直到队列有空闲位置当队列为空时take 方法会阻塞消费者线程直到队列有数据可用。 线程安全内部通过一把锁ReentrantLock和两个条件变量notEmpty、notFull实现线程安全的插入和删除操作。 4.2 生产者 - 消费者模型的典型应用 ArrayBlockingQueue 是生产者 - 消费者模式的经典实现其核心逻辑如下 模型角色 生产者向队列中添加元素如 put、offer 方法消费者从队列中获取元素如 take、poll 方法阻塞队列作为生产者和消费者的中间缓冲区协调两者的速度差异。 4.3 模型优势 解耦生产者和消费者无需直接交互只需关注队列操作缓冲作用平衡生产与消费的速度差异避免生产者因消费者处理慢而阻塞流量控制有界队列天然限制数据积压防止内存溢出如消费者崩溃时。 4.4 与其他阻塞队列的对比 特性ArrayBlockingQueueLinkedBlockingQueueConcurrentLinkedQueue数据结构数组固定容量链表可选有界 / 无界链表无界锁机制单锁ReentrantLock 双条件变量读写分离锁两把锁无锁CAS 操作阻塞特性插入 / 获取均支持阻塞插入 / 获取均支持阻塞非阻塞返回 null 或 false适用场景生产 - 消费场景有界缓冲读写分离场景如日志处理高并发无界场景如监控数据内存效率数组连续存储内存利用率高链表节点有额外开销链表节点有额外开销 4.5 使用场景与注意事项 典型场景 线程池任务队列如 ThreadPoolExecutor 的 workQueue 参数消息中间件的本地缓冲如 Kafka 生产者的内存队列日志收集系统的缓冲队列。 注意事项 容量设置容量过小可能导致生产者频繁阻塞过大可能占用过多内存需根据实际生产 / 消费速度调优性能考量单锁机制在高并发下可能存在竞争若读写操作频繁可考虑 LinkedBlockingQueue读写分离锁或无锁队列阻塞方法选择put/take 会抛出 InterruptedException需正确处理线程中断offer/poll 可设置超时时间避免永久阻塞。
4.6 核心源码逻辑简析
public class ArrayBlockingQueueE extends AbstractQueueE implements BlockingQueueE, java.io.Serializable {private final E[] items; // 存储元素的数组 private int takeIndex; // 取元素的索引 private int putIndex; // 存元素的索引 private int count; // 队列元素数量 private final ReentrantLock lock; // 互斥锁 private final Condition notEmpty; // 队列非空时的通知条件 private final Condition notFull; // 队列非满时的通知条件 // 构造函数指定容量和公平性 public ArrayBlockingQueue(int capacity, boolean fair) { if (capacity 0) throw new IllegalArgumentException(); this.items (E[]) new Object[capacity]; lock new ReentrantLock(fair); notEmpty lock.newCondition(); notFull lock.newCondition(); } // 阻塞插入方法 public void put(E e) throws InterruptedException { checkNotNull(e); final ReentrantLock lock this.lock; lock.lockInterruptibly(); // 可响应中断的加锁 try { while (count items.length) // 队列满时等待 notFull.await(); enqueue(e); // 插入元素 } finally { lock.unlock(); } } // 阻塞获取方法 public E take() throws InterruptedException { final ReentrantLock lock this.lock; lock.lockInterruptibly(); try { while (count 0) // 队列空时等待 notEmpty.await(); return dequeue(); // 取出元素 } finally { lock.unlock(); } } // 其他核心方法略
} 通过以上解析可知ArrayBlockingQueue 通过数组和锁机制实现了有界阻塞队列完美适配生产者 - 消费者模型是并发编程中处理任务缓冲的重要工具。 4.7 LinkedBlockingQueue
LinkedBlockingQueue 是 Java 中另一个非常实用的阻塞队列实现它基于链表结构支持可选的有界和无界模式。与 ArrayBlockingQueue 不同LinkedBlockingQueue 使用了读写分离锁两把锁来提高并发性能特别适合读写分离的场景如日志处理。
4.8 读写分离锁
读写分离锁是一种锁机制通过将读操作和写操作分开管理减少锁的争用从而提高并发性能。LinkedBlockingQueue 使用了两把锁 putLock用于保护队列的插入操作。 takeLock用于保护队列的获取操作。
这种设计允许多个读操作并发执行同时写操作可以独立进行从而减少了锁的争用。
4.9 链表结构
LinkedBlockingQueue 使用链表来存储队列中的元素。链表的每个节点包含一个指向下一个节点的指针这种结构使得插入和删除操作的时间复杂度为 O(1)。然而链表节点的额外开销如指针可能会导致内存利用率略低于数组结构。
5.日志处理场景
在日志处理场景中通常有多个生产者日志生成线程和一个或多个消费者日志处理线程。LinkedBlockingQueue 的读写分离锁机制非常适合这种场景因为它可以高效地处理高并发的写操作和读操作。
5.1 实现日志处理的步骤
1. 创建 LinkedBlockingQueue
import java.util.concurrent.LinkedBlockingQueue;// 创建一个有界队列容量为1000
LinkedBlockingQueueString logQueue new LinkedBlockingQueue(1000);
2. 生产者线程日志生成线程
生产者线程负责生成日志消息并将其放入队列中。如果队列已满生产者线程会阻塞直到队列中有可用空间。
Thread producer new Thread(() - {try {for (int i 0; i 100; i) {String logMessage Log message i;logQueue.put(logMessage); // 放入队列如果队列已满则阻塞System.out.println(生产者生成日志: logMessage);Thread.sleep((int) (Math.random() * 100));}} catch (InterruptedException e) {e.printStackTrace();}
});
3. 消费者线程日志处理线程
消费者线程负责从队列中取出日志消息并进行处理。如果队列为空消费者线程会阻塞直到队列中有新的消息
Thread consumer new Thread(() - {try {while (true) {String logMessage logQueue.take(); // 从队列中取出消息如果队列为空则阻塞System.out.println(消费者处理日志: logMessage);Thread.sleep((int) (Math.random() * 100));}} catch (InterruptedException e) {e.printStackTrace();}
});
4. 启动线程
producer.start();
consumer.start();
完整代码示例
import java.util.concurrent.LinkedBlockingQueue;public class LogProcessingExample {public static void main(String[] args) {// 创建一个有界队列容量为1000LinkedBlockingQueueString logQueue new LinkedBlockingQueue(1000);// 生产者线程日志生成线程Thread producer new Thread(() - {try {for (int i 0; i 100; i) {String logMessage Log message i;logQueue.put(logMessage); // 放入队列如果队列已满则阻塞System.out.println(生产者生成日志: logMessage);Thread.sleep((int) (Math.random() * 100));}} catch (InterruptedException e) {e.printStackTrace();}});// 消费者线程日志处理线程Thread consumer new Thread(() - {try {while (true) {String logMessage logQueue.take(); // 从队列中取出消息如果队列为空则阻塞System.out.println(消费者处理日志: logMessage);Thread.sleep((int) (Math.random() * 100));}} catch (InterruptedException e) {e.printStackTrace();}});// 启动线程producer.start();consumer.start();}
}
输出示例
生产者生成日志: Log message 0
消费者处理日志: Log message 0
生产者生成日志: Log message 1
消费者处理日志: Log message 1
生产者生成日志: Log message 2
消费者处理日志: Log message 2
生产者生成日志: Log message 3
消费者处理日志: Log message 3
...
读写分离锁的优势 高并发性能读写分离锁允许多个读操作并发执行同时写操作可以独立进行减少了锁的争用。 适合高吞吐量场景特别适合日志处理等高吞吐量的场景因为日志生成通常是高频操作而日志处理可以稍慢一些。 总结 LinkedBlockingQueue 是一个非常适合读写分离场景的阻塞队列实现特别是当生产者和消费者线程数量较多时。它的读写分离锁机制可以显著提高并发性能使得日志处理等场景更加高效。 5.2 消息队列的本地缓冲与日志系统的缓冲
1.消息队列的本地缓冲
在消息队列的本地缓冲中生产者消息生成线程和消费者消息发送线程的频率通常是相对一致的但并不总是完全相同。具体来说 生产者频率消息生成的速度取决于应用程序的业务逻辑。例如一个高频交易系统可能会以极高的频率生成消息而一个用户注册系统可能生成消息的频率较低。 消费者频率消息发送的速度取决于远程消息队列的处理能力和网络条件。如果远程队列处理能力很强且网络状况良好消费者可以快速地将消息发送出去反之如果网络延迟较高或远程队列处理能力有限消费者可能会变慢。
尽管生产者和消费者的频率可能不完全相同但它们通常会趋于平衡因为本地缓冲的目的是临时存储消息直到它们被发送到远程队列。如果生产者的速度远远超过消费者缓冲区可能会很快被填满导致生产者阻塞如果消费者速度远远超过生产者缓冲区可能会很快变空导致消费者阻塞。
2.日志系统的缓冲
在日志系统中生产者日志生成线程和消费者日志处理线程的频率通常差异较大具体来说 生产者频率日志生成通常是高频操作尤其是在复杂的系统中可能会有大量的日志消息需要记录。例如一个大型的分布式系统可能会在每个请求处理过程中生成多条日志消息。 消费者频率日志处理的速度取决于日志系统的实现和存储介质。例如将日志写入磁盘或发送到远程日志服务器的速度可能会比日志生成的速度慢得多。此外日志处理可能涉及到复杂的操作如格式化、压缩或持久化这些操作可能会进一步降低处理速度。
由于生产者和消费者的频率差异较大日志系统的缓冲需要能够高效地处理高并发的写操作和读操作以避免生产者阻塞或日志丢失。
5.3 是否需要额外的缓冲层
在日常开发中是否需要对日志系统布置额外的缓冲层取决于具体的应用场景和需求。直接使用日志系统如 Log4j、SLF4J 等通常已经足够满足大多数需求但在某些高性能或高并发的场景中额外的缓冲层可以显著提升性能。
1.不需要额外缓冲层的情况 低并发场景如果应用程序的并发量较低日志生成频率不高直接使用日志系统如 Log4j、SLF4J 等通常已经足够。 简单的日志需求如果日志需求比较简单不需要复杂的异步处理或性能优化直接使用日志系统即可。
2.需要额外缓冲层的情况 高并发场景在高并发的系统中日志生成频率可能非常高直接写入日志文件或远程日志服务器可能会导致性能瓶颈。在这种情况下使用额外的缓冲层如 LinkedBlockingQueue可以有效缓解性能问题。 高性能需求如果需要快速响应用户请求而日志写入操作可能会阻塞主线程使用额外的缓冲层可以将日志写入操作异步化从而提高系统的响应速度。 复杂的日志处理如果日志处理涉及复杂的操作如格式化、压缩、持久化等使用额外的缓冲层可以将这些操作异步化避免阻塞主线程。
5.4 常见的日志系统
1. Log4j
Log4j 是一个非常流行的日志框架支持多种日志级别如 DEBUG、INFO、WARN、ERROR 等并可以配置多种日志输出方式如控制台、文件、远程服务器等。 特点 配置灵活支持多种日志策略。 支持异步日志写入减少对主线程的阻塞。 广泛使用社区支持丰富。 示例代码 import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;public class Log4jExample {private static final Logger logger LogManager.getLogger(Log4jExample.class);public static void main(String[] args) {logger.info(这是一个 INFO 级别的日志);logger.error(这是一个 ERROR 级别的日志);}
}
2. SLF4J
SLF4JSimple Logging Facade for Java是一个日志门面提供了统一的日志接口可以与多种日志框架如 Log4j、Logback 等集成。 特点 提供统一的日志接口便于切换不同的日志框架。 支持多种日志级别和输出方式。 轻量级性能优越。 示例代码 import org.slf4j.Logger;
import org.slf4j.LoggerFactory;public class SLF4JExample {private static final Logger logger LoggerFactory.getLogger(SLF4JExample.class);public static void main(String[] args) {logger.info(这是一个 INFO 级别的日志);logger.error(这是一个 ERROR 级别的日志);}
}
3. Logback
Logback 是一个高性能的日志框架由 Log4j 的创始人 Ceki Gülcü 开发支持异步日志写入和多种日志策略。 特点 高性能支持异步日志写入。 配置灵活支持多种日志策略。 与 SLF4J 集成使用方便。 示例代码 import ch.qos.logback.classic.Logger;
import ch.qos.logback.classic.LoggerContext;
import org.slf4j.LoggerFactory;public class LogbackExample {private static final Logger logger (Logger) LoggerFactory.getLogger(LogbackExample.class);public static void main(String[] args) {logger.info(这是一个 INFO 级别的日志);logger.error(这是一个 ERROR 级别的日志);}
}
4. Log4j2
Log4j2 是 Log4j 的下一代版本提供了更好的性能和更灵活的配置。 特点 高性能支持异步日志写入。 配置灵活支持多种日志策略。 支持多种日志输出方式。 示例代码 import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;public class Log4j2Example {private static final Logger logger LogManager.getLogger(Log4j2Example.class);public static void main(String[] args) {logger.info(这是一个 INFO 级别的日志);logger.error(这是一个 ERROR 级别的日志);}
5.5 示例使用 LinkedBlockingQueue 作为日志缓冲
如果需要在日志系统中使用额外的缓冲层可以使用 LinkedBlockingQueue 来实现异步日志处理。以下是一个简单的示例 import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.TimeUnit;public class AsyncLoggerSystem {private static final Logger logger LogManager.getLogger();private static final LinkedBlockingQueueString logQueue new LinkedBlockingQueue(1000);private static volatile boolean isRunning true;// 日志生产者主线程调用public static void logAsync(String message) {if (!logQueue.offer(message)) {logger.warn(Log queue full, dropping message: message);}}// 日志消费者独立线程static {Thread consumerThread new Thread(() - {while (isRunning || !logQueue.isEmpty()) {try {String msg logQueue.poll(100, TimeUnit.MILLISECONDS);if (msg ! null) {logger.info([ASYNC] msg);}} catch (InterruptedException e) {Thread.currentThread().interrupt();}}});consumerThread.setDaemon(true);consumerThread.start();}public static void shutdown() {isRunning false;}
}5.6 总结 直接使用日志系统在大多数低并发或简单的日志需求场景中直接使用日志系统如 Log4j、SLF4J、Logback 等已经足够。 使用额外的缓冲层在高并发或高性能需求的场景中使用额外的缓冲层如 LinkedBlockingQueue可以有效缓解性能问题将日志写入操作异步化避免阻塞主线程。 根据具体的应用场景和需求选择 合适的方式可以显著提升系统的性能和稳定性。 5.7 日志写很需要毕竟要记录为什么说他的读也很频繁呢
日志系统中读操作频繁的本质原因在于日志不仅是记录载体更是运维、监控、调试的核心数据源。以下是具体场景分析和技术必要性 1.日志读操作高频场景
场景读操作特点技术需求实时监控与告警持续扫描日志关键字如ERROR高并发顺序读日志聚合分析ELK等系统每秒百万级日志索引批量随机读倒排索引生产环境调试开发者实时tail -f追踪请求链路低延迟尾部读安全审计全量扫描日志检测攻击模式大规模顺序扫描数据恢复验证事务完成时校验日志一致性强一致性读 典型读写比例 支付系统日志读占比可达 40%监控20% 审计15% 调试5% 2. 技术实现对读性能的依赖
2.1 检索效率瓶颈
// Log4j2的异步索引构建读性能核心 IndexWriter writer new ConcurrentSortedDoubleBuffer();
writer.addLogEntry(logEvent); // 写操作 // 检索时需要遍历索引读密集
ListLogEvent errors writer.search(ERROR);
问题当日志量达TB级时无索引的全扫描耗时可达小时级
2.2 日志系统架构设计 读密集型环节 Elasticsearch索引构建磁盘IO密集型读Kibana仪表盘渲染高频聚合计算
2.3 存储引擎优化
日志存储方案写优化读优化Lucene索引延迟写内存buffer倒排索引分片查询WAL(Write-Ahead Log)顺序追加写Checkpoint快照内存缓存LSM-Tree写内存MemTable多级SSTable合并扫描 性能对比在机械磁盘上随机读性能比顺序写低100倍1ms vs 0.01ms 3.工业级日志系统的读写平衡设计
3.1 分层存储架构 读写策略 热数据读写均衡SSD加速冷数据写一次读稀少成本优先
3.2 Log4j2异步Kafka配置优化实现
Configuration statuswarnAppendersKafka nameKafkaAppender topiclogs!-- 异步批量传输配置 --AsyncBatchDelivery batchSize500 timeout50!-- 索引加速配置 --Indexing enabledtrueField namelevel pattern%level/Field nametraceId pattern%X{traceId}//Indexing/AsyncBatchDeliveryPatternLayout pattern%d{ISO8601} %p %c{1.} [%t] %m%n/Property namebootstrap.serverskafka1:9092,kafka2:9092/Property/Kafka/AppendersLoggersRoot levelinfoAppenderRef refKafkaAppender//Root/Loggers
/Configuration3.3 读写分离部署
写节点专注接收日志批量持久化读节点承载查询请求内置缓存如Redis缓存热点日志 4.忽视读性能的代价
监控延迟关键错误10分钟后才告警故障排查受阻生产问题查询超时用户体验下降安全风险攻击日志未能实时分析导致入侵扩大合规风险审计报表无法按时生成违反SOX等法规 根据AWS案例研究优化日志读性能可使MTTR平均修复时间降低65% 5. 总结建议
读写同权设计选择LSM-Tree或倒排索引的日志库如Log4j2Lucene冷热分离实时日志用SSD历史日志用压缩存储异步索引在日志写入时并行构建检索索引资源隔离读写操作分配独立线程池避免相互阻塞 日志系统的价值不在记录而在使用高效的读能力直接决定运维效能和业务连续性。 5.8 存储引擎优化
1. Lucene 索引面向检索场景的日志存储方案
1.1 写优化延迟写内存 Buffer
核心原理将日志数据先写入内存缓冲区攒够一定量或达到时间阈值后再批量写入磁盘。优化价值 减少磁盘随机写次数磁盘随机写速度约为内存操作的 1/1000。避免小文件碎片化提升后续读写效率。 典型案例 日志收集系统如 ELK Stack 中的 Logstash接收日志时先将日志暂存于内存 Buffer当 Buffer 满 512MB 或每 10 秒触发一次批量落盘降低 IO 开销。
1.2 读优化倒排索引 分片查询
倒排索引优化 原理将 “日志文档 - 关键词” 映射为 “关键词 - 文档列表”查询时直接定位包含关键词的日志。案例查询 “ERROR 级别日志” 时倒排索引直接返回所有包含 “ERROR” 的日志文档 ID无需扫描全量数据查询时间从 O (n) 降至 O (log n)。 分片查询优化 原理将索引拆分为多个分片Shard多节点并行查询后合并结果。案例Elasticsearch 存储 10 亿条日志时将索引分为 10 个分片查询时 10 个节点同时扫描各自分片1 秒内返回结果比单节点查询快 10 倍。 Redis 的局限性 Redis 不支持倒排索引需要手动实现复杂度高且效率低。 Redis 的查询功能有限不支持复杂的全文搜索。 Elasticsearch 的优势 内置倒排索引支持高效的全文搜索。 提供丰富的查询功能可以轻松实现复杂的查询需求。 Redis 的局限性 Redis 是单线程的虽然可以通过分片Sharding来扩展但分片需要手动管理复杂度高。 Redis 不支持分布式查询和结果合并需要应用层实现效率低。 Elasticsearch 的优势 内置分片和副本机制支持分布式查询和结果合并。 支持水平扩展可以通过增加节点来提升性能。 提供丰富的查询功能支持复杂的分析和聚合。 2.WAL写前日志面向可靠性的日志持久化方案
2.1 写优化顺序追加写
核心原理所有写操作按顺序追加到日志文件末尾不修改已有数据。优化价值 磁盘顺序写速度约 200MB/s远高于随机写约 100KB/s提升写入吞吐量。顺序写结构简单无需磁盘寻址减少 CPU 开销。 典型案例 MySQL 的 InnoDB 引擎将事务日志按顺序写入 Redo Log 文件即使每秒 10 万次写入仍能保持稳定性能因顺序写接近内存速度。
2.2 读优化Checkpoint 快照 内存缓存
Checkpoint 快照优化 原理定期生成数据快照记录当前状态故障恢复时只需重放快照后的日志。案例Kafka 的分区日志通过 Checkpoint 记录已提交偏移量当 Broker 重启时只需从最新 Checkpoint 后的日志开始恢复而非扫描全量日志恢复时间从小时级降至秒级。 Kafka 优化的是 “磁盘日志的恢复效率”Redis 优化的是 “内存数据的重建效率”两者因数据存储介质、业务场景的不同选择了截然不同的持久化与恢复策略 内存缓存优化 原理将热点日志数据缓存在内存加速读取。案例ZooKeeper 将事务日志的最近部分缓存在内存客户端查询时直接从内存返回避免磁盘 IO读性能提升 10 倍以上。 这种架构选择体现了系统设计中的垂直整合原则——针对特定场景日志处理深度优化比通用方案Redis更符合数据访问特性和业务需求。 3.LSM-Tree面向高并发写入的日志存储方案
3.1写优化写内存 MemTable
核心原理写操作先写入内存中的有序数据结构MemTable立即返回成功异步刷盘。优化价值 写操作性能接近内存速度约 100 万次 / 秒远超磁盘随机写。内存批量刷盘为顺序写降低 IO 次数。 典型案例 时序数据库 InfluxDB 存储监控日志时写操作先存入 MemTable跳表结构当 MemTable 满 2MB 时转为 Immutable MemTable再异步刷盘为 SSTable实现每秒 10 万次以上写入。
3.2读优化多级 SSTable 合并扫描
核心原理 内存 MemTable 写满后转为磁盘 SSTable有序键值对文件多层 SSTable 按时间排序。查询时从内存到磁盘多层扫描合并结果后台定期合并小 SSTable 为大文件减少读时扫描层级。 优化案例 RocksDBLSM-Tree 实现在查询时先查内存 MemTable再查 Immutable MemTable最后查磁盘 SSTable多层。例如查询最新 10 分钟的日志时90% 的请求可在内存中命中仅 10% 需访问磁盘。后台合并会将 100 个小 SSTable 合并为 1 个大文件下次查询时扫描层数从 100 层降至 1 层读性能提升 100 倍。
4.三种方案的优化策略对比
方案写优化核心思路读优化核心思路典型应用场景Lucene 索引内存 Buffer 批量写减少随机 IO倒排索引快速定位分片并行查询日志检索ELK Stack、全文搜索WAL顺序追加写利用磁盘顺序 IO 优势Checkpoint 减少恢复时间内存缓存热点数据数据库事务日志、消息队列KafkaLSM-Tree内存 MemTable 加速写异步顺序刷盘多层 SSTable 合并减少读时扫描内存优先查询时序数据库InfluxDB、KV 存储RocksDB
5.实际场景中的优化策略选择
读多写少场景如日志检索优先选 Lucene 索引利用倒排索引加速查询。强一致性场景如金融日志优先选 WAL通过顺序写保证数据不丢失Checkpoint 确保快速恢复。高并发写入场景如实时监控日志优先选 LSM-Tree用内存写提升吞吐量后台合并平衡读性能。
通过上述优化日志存储系统可在不同业务场景下实现写入性能提升 10-100 倍查询响应时间压缩至毫秒级。
5.9 Redis和ZooKeeper对比
1.Redis 不可替代场景举例
高频读缓存10万 QPS 的热点数据缓存如商品详情页实时排行榜基于 Sorted Set 的实时榜单更新如游戏积分榜会话共享分布式系统会话存储用户登录状态跨服务同步消息队列通过 Stream 或 Pub/Sub 实现轻量级消息传递
2.为何 Redis 不能替代 ZooKeeper
2.1协调类场景缺陷
分布式锁 Redis 锁依赖过期时间存在锁提前释放风险需复杂续期逻辑25ZooKeeper 通过临时顺序节点实现锁自动释放客户端断开即删除26 服务发现 Redis 无原生服务状态监听机制需轮询检测ZooKeeper 通过 Watcher 实时推送节点变化
2.2 强一致性需求
场景集群选主、配置中心如数据库主从切换 ZooKeeper 保证所有节点数据视图一致Redis 异步复制可能导致读取旧 3.Redis 的独特优势
3.1 高性能读写
内存操作读写延迟 1ms支撑百万级并发8对比ZooKeeper 写需磁盘同步延迟 10ms6
3.2丰富数据结构
# Redis 实现秒杀库存扣减原子操作
redis_client.set(stock:1001, 100)
# 初始化库存 redis_client.decr(stock:1001)
# 原子减库存避免超卖
3.3 持久化与高可用
RDB/AOF故障恢复能力ZooKeeper 默认仅内存Redis Cluster自动分片、故障转移 6. 设计思想对比
锁粒度优化如ConcurrentHashMap分段锁 vs Hashtable全局锁读写分离CopyOnWrite系列通过数据副本避免读写冲突无锁算法ConcurrentLinkedQueue使用CAS提升并发度 7. 选型建议
读多写少优先CopyOnWrite系列高并发写入选择ConcurrentHashMap或ConcurrentLinkedQueue有序需求考虑ConcurrentSkipListMap 2. 对象池
2.1 传统方案ReentrantLock
使用 ReentrantLock 来保护对象池的访问。
import java.util.concurrent.locks.ReentrantLock;public class ObjectPool {private final ReentrantLock lock new ReentrantLock();private final ListObject pool new ArrayList();public Object borrowObject() {lock.lock();try {return pool.remove(0);} finally {lock.unlock();}}public void returnObject(Object obj) {lock.lock();try {pool.add(obj);} finally {lock.unlock();}}
} 2.2 优化方案StampedLock 乐观读
StampedLock 是 Java 8 引入的一种高性能锁支持乐观读和悲观写。
import java.util.concurrent.locks.StampedLock;public class ObjectPool {private final StampedLock lock new StampedLock();private final ListObject pool new ArrayList();public Object borrowObject() {long stamp lock.readLock();try {return pool.remove(0);} finally {lock.unlockRead(stamp);}}public void returnObject(Object obj) {long stamp lock.writeLock();try {pool.add(obj);} finally {lock.unlockWrite(stamp);}}
}
性能提升 传统方案ReentrantLock 是一种重量级的锁会导致线程阻塞和上下文切换。 优化方案StampedLock 支持乐观读减少了锁的开销性能提升约 3 倍。
2.3 乐观锁
乐观锁Optimistic Locking是一种在数据库管理和多线程编程中用于处理并发控制的机制。它的核心思想是假设数据在大多数情况下不会发生冲突因此在读取数据时不加锁而是在更新数据时才检查是否有冲突。如果检测到冲突则会采取相应的措施如重试或回滚。
1.乐观锁的工作原理 读取数据 当一个线程读取数据时不会对数据加锁。 线程会记录数据的当前版本号Version Number或时间戳Timestamp。 修改数据 当线程准备更新数据时会检查数据的版本号或时间戳是否发生变化。 如果版本号或时间戳没有变化说明数据在读取和更新之间没有被其他线程修改可以安全地进行更新。 如果版本号或时间戳发生了变化说明数据在读取和更新之间被其他线程修改过此时会触发冲突处理机制如重试或回滚。 更新数据 如果没有冲突更新数据并增加版本号或更新时间戳。 如果有冲突可以选择重试操作或回滚操作。
2.乐观锁的实现方式
2.1 基于版本号Version Number 在数据库表中增加一个版本号字段通常是一个整数。 每次更新数据时版本号加1。 更新操作时检查版本号是否发生变化。
示例 SQL 语句
-- 假设有一个表 items包含字段 id, name, version
UPDATE items
SET name new_name, version version 1
WHERE id 1 AND version 10;
2.2 基于时间戳Timestamp 在数据库表中增加一个时间戳字段通常是一个 TIMESTAMP 或 DATETIME 类型。 每次更新数据时更新时间戳。 更新操作时检查时间戳是否发生变化。
示例 SQL 语句
-- 假设有一个表 items包含字段 id, name, timestamp
UPDATE items
SET name new_name, timestamp NOW()
WHERE id 1 AND timestamp 2024-06-13 12:00:00;
2.3 乐观锁的优点 减少锁的开销 乐观锁在读取数据时不加锁减少了锁的开销提高了系统的性能。 适用于读多写少的场景可以显著提高并发性能。 避免死锁 由于乐观锁不使用传统的锁机制因此不会出现死锁问题。 提高吞吐量 在大多数情况下数据不会发生冲突因此可以快速完成更新操作提高系统的吞吐量。
2.4 乐观锁的缺点 冲突处理 如果数据冲突频繁发生系统需要频繁地处理冲突如重试或回滚这可能会导致性能下降。 适用于冲突较少的场景如果冲突频繁可能会导致大量重试影响性能。 实现复杂 乐观锁的实现相对复杂需要额外的逻辑来处理冲突。 需要记录版本号或时间戳并在更新时进行检查。
2.5 适用场景 读多写少的场景适用于大部分时间数据不会被修改的场景如在线交易系统中的订单状态更新。 高并发场景适用于高并发的系统可以减少锁的开销提高性能。 分布式系统在分布式系统中乐观锁可以减少锁的协调开销提高系统的可扩展性。
2.6 示例代码
以下是一个简单的 Java 示例使用乐观锁机制更新数据库中的数据
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;public class OptimisticLockingExample {public static void main(String[] args) {// 假设有一个数据库连接Connection connection null;try {// 读取数据String selectSql SELECT id, name, version FROM items WHERE id ?;PreparedStatement selectStmt connection.prepareStatement(selectSql);selectStmt.setInt(1, 1);ResultSet resultSet selectStmt.executeQuery();if (resultSet.next()) {int id resultSet.getInt(id);String name resultSet.getString(name);int version resultSet.getInt(version);// 模拟修改数据String newName new_name;// 更新数据String updateSql UPDATE items SET name ?, version version 1 WHERE id ? AND version ?;PreparedStatement updateStmt connection.prepareStatement(updateSql);updateStmt.setString(1, newName);updateStmt.setInt(2, id);updateStmt.setInt(3, version);int rowsAffected updateStmt.executeUpdate();if (rowsAffected 0) {System.out.println(更新失败数据已被其他线程修改);} else {System.out.println(更新成功);}}} catch (SQLException e) {e.printStackTrace();} finally {// 关闭数据库连接if (connection ! null) {try {connection.close();} catch (SQLException e) {e.printStackTrace();}}}}
}
2.7 总结
乐观锁是一种高效的并发控制机制适用于读多写少的场景。它通过减少锁的开销提高了系统的性能和吞吐量。然而乐观锁需要额外的逻辑来处理冲突且在冲突频繁的场景中可能会导致性能下降。选择合适的锁机制需要根据具体的应用场景和需求来决定。
3. 缓存更新
3.1 传统方案全局锁
使用全局锁来保护缓存的更新操作。
import java.util.Map;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;public class Cache {private final MapString, Object cache new HashMap();private final Lock lock new ReentrantLock();public Object get(String key) {lock.lock();try {return cache.get(key);} finally {lock.unlock();}}public void put(String key, Object value) {lock.lock();try {cache.put(key, value);} finally {lock.unlock();}}
}
3.2 优化方案ConcurrentHashMap 分段
ConcurrentHashMap 是 Java 提供的线程安全的哈希表支持分段锁性能更高。
import java.util.concurrent.ConcurrentHashMap;public class Cache {private final ConcurrentHashMapString, Object cache new ConcurrentHashMap();public Object get(String key) {return cache.get(key);}public void put(String key, Object value) {cache.put(key, value);}
}
3.3 性能提升 传统方案全局锁会导致所有线程在更新缓存时排队等待。 优化方案ConcurrentHashMap 使用分段锁减少了锁的粒度性能提升约 15 倍。
2.2 伪共享False Sharing解决
伪共享False Sharing是指多个线程访问或修改共享缓存行中的不同变量时导致缓存行频繁失效从而降低性能。解决伪共享问题的一种方法是填充缓存行避免不同变量共享同一个缓存行。
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;Retention(RetentionPolicy.RUNTIME)
Target(ElementType.TYPE)
public interface Contended {
}Contended
public class Counter {private volatile long value 0;public void increment() {value;}public long getValue() {return value;}
}详细说明
Contended 注解
Contended 是 Java 8 引入的一个注解用于标记类或字段避免伪共享问题。
它会自动填充缓存行确保不同变量不会共享同一个缓存行。
填充缓存行
在 64 字节架构中缓存行的大小为 64 字节。
Contended 注解会自动填充 56 字节确保 value 字段独占一个缓存行。
性能提升
通过填充缓存行避免了伪共享问题减少了缓存行的无效化从而提高了性能。
1.什么是伪共享
伪共享是多核 CPU 架构下的性能陷阱发生在以下场景
硬件背景现代 CPU 访问内存时不是直接读写单个变量而是以缓存行为单位通常 64 字节加载到 L1/L2/L3 缓存问题本质当两个线程修改同一缓存行中的不同变量时即使变量逻辑上不相关也会导致缓存行频繁失效和刷新造成性能下降
2 伪共享的危害
性能下降缓存行失效会触发从内存重新加载耗时约 100 倍于直接访问缓存可观测现象多核 CPU 下线程越多性能反而越差与预期的线性增长相反
3 伪共享实例解析
假设我们有一个计数器类
class Counter {long value1; // 8字节long value2; // 8字节// 其他字段...
}在 64 字节的缓存行中value1 和 value2 会被加载到同一缓存行
缓存行布局64字节:
[value1(8B) | value2(8B) | 填充(48B)]现在假设有两个线程
线程 A 修改 value1线程 B 修改 value2
尽管两个变量逻辑上独立但由于它们共享同一缓存行会发生以下情况
线程 A 修改 value1导致整个缓存行失效线程 B 需要重新从内存加载该缓存行线程 B 修改 value2又导致缓存行失效线程 A 需要再次从内存加载该缓存行
这种频繁的缓存行失效和重新加载会导致性能急剧下降。
4 解决方案缓存行填充
通过在变量之间添加足够的填充确保每个变量独占一个缓存行
class Counter {// 填充前8个long共64字节long p0, p1, p2, p3, p4, p5, p6, p7;// 实际使用的变量long value1;// 填充后8个long共64字节long p8, p9, p10, p11, p12, p13, p14, p15;// 填充前8个long共64字节long q0, q1, q2, q3, q4, q5, q6, q7;// 实际使用的变量long value2;// 填充后8个long共64字节long q8, q9, q10, q11, q12, q13, q14, q15;
}现在缓存行布局变为 缓存行1: [p0-p7(64B) | value1(8B) | p8-p15(56B)]
缓存行2: [q0-q7(64B) | value2(8B) | q8-q15(56B)]线程 A 和线程 B 现在访问不同的缓存行互不干扰性能大幅提升。
5.Java 8 中的 Contended 注解
Java 8 引入了 Contended 注解简化填充操作
import sun.misc.Contended;class Counter {Contendedlong value1;Contendedlong value2;
}需要添加 JVM 参数启用-XX:-RestrictContended
6.性能对比测试
以下是一个简单的测试代码展示伪共享的影响
import java.util.concurrent.CountDownLatch;public class FalseSharing {public static final int NUM_THREADS 4;public static final long ITERATIONS 500L * 1000L * 1000L;private final static class VolatileLong {public volatile long value 0L;// 填充代码...}public static VolatileLong[] longs new VolatileLong[NUM_THREADS];static {for (int i 0; i longs.length; i) {longs[i] new VolatileLong();}}public static void main(String[] args) throws Exception {final CountDownLatch startLatch new CountDownLatch(1);Thread[] threads new Thread[NUM_THREADS];for (int i 0; i threads.length; i) {final int index i;threads[i] new Thread(() - {try {startLatch.await();for (long j 0; j ITERATIONS; j) {longs[index].value j;}} catch (InterruptedException e) {e.printStackTrace();}});}long start System.nanoTime();startLatch.countDown();for (Thread t : threads) {t.start();}for (Thread t : threads) {t.join();}System.out.println(Duration: (System.nanoTime() - start) / 1_000_000_000.0);}
}未填充版本执行时间约 20 秒填充版本执行时间约 2 秒性能提升 10 倍
7.实际应用场景
高性能队列Disruptor 框架使用缓存行填充技术避免生产者和消费者指针的伪共享计数器LongAdder 内部使用 Cell 数组每个 Cell 独立一个缓存行线程本地数据ThreadLocalRandom 通过缓存行填充避免多线程访问时的伪共享
8.何时需要关注伪共享
高并发场景下的性能调优对延迟极度敏感的系统如高频交易频繁修改共享变量的场景
9.总结
伪共享是多核编程中隐蔽但影响巨大的性能陷阱通过合理的缓存行填充可以有效避免。在设计高性能并发系统时理解硬件架构和缓存行为是必不可少的技能。
