Java ✨

昨天，有人跟我聊起项目中对程序的优化，有一个特别有意思的话题《如何榨干一台机器的CPU》 现在的市面上，多核CPU是主流，有了多核的加持，可以更加有效的发挥硬件的能力，基于Java程序，我们究竟该如何更加有效的应用多核的能力？我个人经验来讲，主要考虑一下几个方面： 并行执行任务 减少共享数据的写操作 采用合适的方式处理竞争资源 减少数据拷贝次数 合适的GC 接下来详细说明。 1. 并行执行任务 合理利用多线程执行任务，可以有效的发挥CPU的多核性能。由于超线程技术的存在，实际上CPU可以并行执行的线程数量通常是物理核心数量的2倍。 我们都知道，在计算机中，进程是操作系统资源（内存、显卡、磁盘）分配的最小单位。线程是CPU执行调度的最小单位。 因此，实现并行计算的方式大体上有三种：多进程、多线程、多进程+多线程。具体采用哪种方式，就需要实际情况实际分析了。整体指导方针是：如果多线程可以解决，就不要尝试引入多进程。因为每个进程之间是独立的，多进程任务难免会涉及到进程之间通信，而进程之间的协调与通信通常会比较复杂。容易为程序引入额外的复杂度，得不偿失。 2. 减少共享数据的写操作 深入到线程中，每个线程都有自己的内存空间，在这个内存中，线程可以随意进行读写。因此多线程任务中，提高效率的优化手段之一就是： 尽量避免多个线程共同操作共享资源，如果条件允许，尽量采用以空间换时间的方式，将数据复制多份保存在每个线程单独的内存空间中。 如果必须存在共享内存的操作，我们的措施通常是，尽量减少共享数据的写操作，在共享内存中，多个线程的读操作是不存在资源的竞争的。一旦涉及到写共享内存，通常会使用 volatile 关键字保证内存数据对多个线程的可见性，这种情况下就不可避免的要涉及到插入内存屏障指令，用来保证处理器对指令的执行顺序不会打乱。相比不存在内存屏障的操作，性能会有所下降。 因此，需要尽量减少多个线程对共享内存的写操作。具体的方案是： 通过业务逻辑控制，在程序设计之初，排除掉共享数据的方案 在每个线程内部创建单独的对象，互不影响 使用 ThreadLocal 生成线程的本地对象副本 3. 采用合适的方式处理竞争资源 多线程任务中，涉及到资源竞争的部分，通常都需要采用对应的措施来保证资源的一致性。常见的解决方案有两种： 对资源加线程锁 采用乐观策略实现无锁操作（CAS） 线程锁的使用： 使用线程锁来保证资源的一致性是由来已久的一种非常简单便捷的方法。这种操作可以粗暴的控制多个线程对资源的访问，所以在处理多线程资源竞争关系的时候，我们通常会优先想到加锁的方式。 为了提高执行性能，通常会采用轻量级锁来代替重量级锁，在 Java 1.5 中 synchronize 是一个重量级锁，是相对低效率的；相比之下使用 Lock 对象的性能更高一些。但是这种情况到了 Java 1.6 发生了很大的变化，由于官方对 synchronize 引入了适应自旋、锁消除、轻量级锁、偏向锁等优化手段， synchronize 与 Lock 在性能上不存在什么差距。所以如果你使用高于 Java 1.6 的版本，请放心大胆的使用 synchronize 。 无锁操作（CAS）： 对于传统的加锁操作，我们通常认为是悲观策略。相对于悲观策略，我们还有一个乐观策略可以选择。乐观策略认为不会存在资源不一致的情况，假如出现了，就再试一次。 实际上在 Java 中，一些锁的实现也利用了 CAS，体现在 Java 中的应用如下： 应用领域 示例 java....

在我的工作中，数据处理占据了比较大的权重。在数据处理的过程中，有一项比较繁琐的工作，就是对日志中的每个字段进行单独校验和处理，校验的内容大概有以下几类： 字段数量校验 字段为空判断 字段内容校验 特殊字段校验、信息补充 增加标签字段 在这类场景中，最常规的方法就是编写冗长的 if-else 代码段进行按部就班的校验，这显然不是最佳方案。 责任链模式可以有效地解决上述繁琐的工作。通过将不同的校验和处理逻辑分配给不同的处理者，形成一条责任链，数据依次通过各个处理者进行处理。这样做的好处是： 避免编写大量的重复 if-else 代码 将每个校验逻辑进行隔离，区分责任边界 逻辑清晰，代码简洁 以下是一个简单的责任链模式代码示例： public class ChainHandler { private List<Handler> handlers; public ChainHandler() { this.handlers = new ArrayList<>(); } public void addHandler(Handler handler) { handlers.add(handler); } public boolean handle(LogEntry logEntry) { for (Handler handler : handlers) { handler.handle(logEntry); if (!handler.isComplete()) { return false; // 如果处理程序未完成，则整个处理链失败 } } return true; // 如果所有处理程序均完成，则整个处理链成功 } } // 定义责任链接口 public interface Handler { boolean isComplete(); void handle(LogEntry logEntry); } // 字段数量校验 public class FieldCountHandler implements Handler { @Override public boolean isComplete() { // 检查字段数量是否满足要求 return true; } @Override public void handle(LogEntry logEntry) { // 进行字段数量的校验和处理 } } 在上述代码中，ChainHandler 类管理责任链中的处理者。FieldCountHandler 是处理字段数量的实现。...

在电商等需要在线支付的应用中，通常需要设置订单自动取消的功能。本文将介绍几种在 Spring Boot 中实现订单 30 分钟自动取消的方案，包括定时任务、延迟队列和 Redis 过期事件。 方案一：定时任务 定时任务是一种简单且常用的实现订单自动取消的方案。在 Spring Boot 中，可以使用注解@Scheduled来定义定时任务，任务会按照指定的时间间隔执行。在这个方案中，我们可以定义一个定时任务，每隔 30 分钟检查一次未支付的订单，如果订单生成时间超过 30 分钟，则自动取消该订单。 代码示例： import org.springframework.scheduling.annotation.EnableScheduling; import org.springframework.scheduling.annotation.Scheduled; import org.springframework.stereotype.Component; @EnableScheduling @Component public class OrderCancelSchedule { @Autowired private OrderService orderService; @Scheduled(cron = "0 0/1 * * *?") public void cancelUnpaidOrders() { List<Order> unpaidOrders = orderService.getUnpaidOrders(); unpaidOrders.forEach(order -> { if (order.getCreationTime().plusMinutes(30).isBefore(LocalDateTime.now())) { orderService.cancelOrder(order.getId()); } }); } } 在上面的代码中，我们定义了一个名为OrderCancelSchedule的组件，并使用@EnableScheduling注解启用定时任务功能。在组件中，我们定义了一个名为cancelUnpaidOrders的方法，并使用@Scheduled注解来指定该方法作为定时任务执行。cron表达式"0 0/1 * * *?"表示任务每隔 1 分钟执行一次。 方案二：延迟队列 延迟队列是一种将任务延迟执行的机制，入队的元素在一定的延迟时间之后才能出队。在这个方案中，我们可以将订单的 ID 放入延迟队列中，并设置延迟时间为 30 分钟。当延迟时间到期时，从队列中取出订单 ID，并执行取消订单的操作。...

在构建基于 Kafka 的消息处理系统中，消息丢失是一个需要深入研究的重要问题。强大的系统不仅依赖于其功能，而且依赖于其可靠性。因此，理解消息丢失的原因，并采取必要的措施确保消息的一致性和完整性，是构建高效可靠消息系统的重要组成部分。本文将详细分析 Kafka 消息丢失的主要原因，并提供一系列策略来解决这个问题。 消息丢失的原因 生产者端问题： 在 Kafka 系统中，生产者负责发送消息。然而，由于网络故障或其他未知问题，生产者可能无法成功发送消息到 Kafka 服务器。 Kafka 服务端问题： Kafka 服务器可能会因为硬件故障、磁盘满或其他异常情况导致消息丢失。 消费者端问题： 消费者负责处理接收到的消息。但是，消费者在处理消息时可能会出现错误或崩溃，导致消息未被正确处理。 解决方案与措施 生产者端相关方案与措施 发送消息处理回调方法 由于消息的常规发送采用的异步方式，所以通常会忽略掉回调处理，为了保证消息的发送质量，一定需要对回调信息进行处理或者改为同步发送。 producer.send(new ProducerRecord<>(topic, messageKey, messageStr), new CallBack({...}); 设置有效的重试策略以及 acks 配置 我们可以在生产者端设置一个有效的重试策略，保证消息成功发送。例如，我们可以使用指数退避算法进行重试。这种算法会在每次重试失败后等待更长的时间，从而减轻服务器的压力，并增加消息成功发送的概率。 通过设置 Producer acks 机制，我们可以确保生产者收到 Kafka 服务器的确认，知晓消息是否被成功提交。 acks=0： 生产者在发送消息后不会等待任何确认，直接将消息视为发送成功。这种设置下，可能会出现消息丢失的情况，因为生产者不会等待服务器的任何确认即认为消息发送成功。 acks=1： 生产者在发送消息后会等待 Leader Broker 的确认，确认后即视为消息发送成功。这种设置下，消息的可靠性得到一定程度的保证，但仍有可能发生 Leader Broker 宕机导致消息丢失的情况。 acks=all： 生产者在发送消息后会等待 Leader Broker 和所有副本的确认，确认后才视为消息发送成功。这种设置下，消息的可靠性和一致性得到最高级别的保证，但同时也会增加网络延迟和资源消耗。 import org.apache.kafka.clients.producer.*; import org.apache.kafka.common.serialization.StringSerializer; import java.util.Properties; public class KafkaProducerExample { private static final String TOPIC_NAME = "my-topic"; private static final String BOOTSTRAP_SERVERS = "localhost:9092"; public static void main(String[] args) { Properties props = new Properties(); props....