经验分享 ✨

昨天，有人跟我聊起项目中对程序的优化，有一个特别有意思的话题《如何榨干一台机器的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，并执行取消订单的操作。...

今天早上无聊闲逛，看到有不少人是从我的 Obsidian + Hugo 系列，开始了解原来 Obsidian 和 Hugo 还可以这么搭配的。 但是不少人反馈，根据 Hugo 博客写作最佳实践 和 Obsidian + Hugo 最佳配置推荐 这两篇文章操作起来感觉确实方便了，但是方便的不多。整个流程没有非常流畅。甚至感觉有些流程设计的过于繁琐。 不否认，确实是这种感觉，问题在我。 实际上这是我设计的一整套流程，但这两篇博客只讲了关键的一部分，还有一些细枝末节没有讲出来。 所以我临时决定再增加一篇文章说明，把整套流程讲清楚。担心表达能力欠佳，我还录了视频辅助大家理解。 中心思想 整个流程设计的中心思想就是：解决繁琐的操作流程，把操作自动化+高度集中，解放思想，精力都用在写作上。 管理面板 在 Obsidian 的诸多插件的加持下，最终实现所有管理功能集成在一个管理中心，效果如下： 上图中的内容共分为几部分： 统计图，这里只根据发布情况做了发布占比统计，大家完全可以根据自己的需求设计更美观实用的统计图表 操作按钮+笔记：共集成了三个操作按钮，点击新建博客按钮可以根据模板自动创建一篇空白文章；点击发布博客按钮可以把博客内容自动推送到 github，从而触发 github action 自动部署流程；点击获取更新按钮可以从github上同步最新的仓库内容。 草稿箱：使用 dataview 插件，把草稿内容列举出来，归集为草稿箱，直接点击对应草稿便可以开始编辑内容 已发布：把所有已经发布的内容列举出来，方便查看 视频演示 以下视频演示了整个 新建 -> 写作 -> 发布 流程，一刀未剪 技术细节 接下来说一下技术细节。说实话，这里其实并没有太多技术细节，只是一层窗户纸罢了，只要一捅破，大家瞬间就明白了，看到这里应该有很多人已经可以明白实现原理了。 基于 Hugo 博客写作最佳实践 这篇文章，我们可以通过 QuickAdd 插件实现各种自动化命令，在此基础上，只需要增加一个 Buttons 插件，便可以把命令通过点击按钮的方式进行调用。 Buttons 插件安装完成之后，在首页添加如下代码： 新建博客按钮代码 发布博客按钮代码 获取更新按钮代码 总结 以上就是全部内容了，没有什么高深的技术内容，都是一些插件运用的技巧。 有了这个管理面板之后，你是不是可以把精力全部放在写作上了呢？...

如果我们想实现一个简易的 WAF，我们实际上需要干什么？我们需要先了解什么是 WAF。 🐭 什么是 WAF WAF 全称 Web Application Firewall，是一种工作在应用层（7 层）的防火墙，主要用于对应用层中的 HTTP 流量进行监测、过滤和阻止。主要适用于 Web 应用中存在的已知的安全漏洞，例如：SQL 注入、CSRF 跨站请求伪造攻击、XSS 跨站脚本攻击等。 其主要防护原理是基于规则匹配，通过预制的识别规则，对 HTTP 协议中提取出来的信息进行匹配，如果可以匹配，则该请求被认为是攻击行为。WAF 将会对其执行相关的操作（告警、阻断、记录日志）。 综上所诉，WAF 的基本原理如下： 那么回到问题，什么是 WAF 呢？ WAF 是一个工作在应用层，主要针对 HTTP 流量进行解析、检测的装置；其检测功能主要基于规则引擎，通过预制规则，对流量中的相关信息进行匹配，能够针对流量中的 SQL 注入、CSRF、XSS 等 Web 攻击行为进行识别与防护，防护手段主要有告警、阻断、记录日志。 🐮 WAF 通常部署在哪里 从形态上来讲， WAF 主要分为软件型 WAF 和硬件型 WAF 软件型 WAF 主要以嵌入的形式进行部署，一般部署在 Web 服务器中，常见的例如 nginx waf、apache waf、openresty waf 等。 硬件型 WAF 主要通过软件绑定硬件的方式，其部署方式多种多样，以下内容中的 WAF 默认指代硬件 WAF。 WAF 的部署模式通常有： 反向代理、透明代理、透明桥、流量镜像等方式。 反向代理 客户与 WAF 进行交互，WAF 将客户的请求直接转发至后端，后方的 Web Server 与 WAF 进行交互，不会直接暴漏给客户。...

我是一个很容易焦虑的人，大部分焦虑都源自经济压力。 我也是一个很理想主义的人，始终妄想着能够做出一款为大家所认可的产品，随之产生睡后收入。 我还是一个很悲观的人，在做产品的过程中，随着不断的自我反思，会不断陷入：这个东西有人做了；这个东西不会有市场的；这个东西不是一个人能做出来的。等等类似的自我怀疑中。 这些年有不少想法，做了不少工作，但是都胎死腹中，分享出来供大家消遣。我的 Github 签名是 “废材程序员”，真是太贴切了。 treehole-jekyll (一个有点想法的博客系统) 一个包含完整前后端功能的博客系统，使用 Java 开发，采用 sqlite 作为数据库，兼容了 Jekyll 的主题。 部署在小水管云服务器中，后因为优化力度不够+Java对内存的优化确实不是很好，导致小水管只够跑一个博客服务。不能忍受资源浪费，遂放弃自建服务回到 Github Pages 的怀抱。省心省力省钱。 Solid (为博客开发的模板引擎) 在上诉博客系统开发过程中，为了兼容 Jekyll 模板引擎语法，开发的基于 Java 的模板引擎，可以嵌入到 Springboot 中作为视图渲染引擎进行使用。后一直闲置至今。 Hermes (基于 RSS 的文章聚合推荐平台) 有一段时间特别痴迷 RSS，而当时市面上的 RSS 阅读器并没有独角兽的出现，找来找去没找到合适的，所以就种下了 “我要开发一个的蛊”，后来来来回回做了好几个， hermes 算是整体完成度比较高的一个。具备完整的前端+后台+RSS爬虫+任务调度。 还做过一个叫 Miner 的应用，后来也不了了之了。 专注了吗小程序 前段时间逛论坛的时候，发现微信小程序个人认证的费用降到了 30 块，本着宁可不用不能没有的原则赶紧充值上车了。 又本着空着也是空着，总要放点什么的原则，做了这款专注了吗的小程序。主打任务专注管理。 AI 套壳工具 AI 突然就火了，套壳工具如雨后春笋般冒出来，做肯定要做一个的，但是由于聊天回应特别慢，接口延迟的问题一直没法解决，所以一直也没进行推广。想用的可以联系我在后台免费加套餐。花钱暂时就免了吧。 cockroach2 (开源 java 爬虫框架) 有一段时间，对爬虫特别痴迷，而且正好那段时间在研究 Java 的对象管理，索性整合一下做了一个爬虫框架。主打用尽可能少的配置、写出一个灵活、健壮的爬虫。当时在第一个版本出来的时候还许下豪言，要做真正的分布式爬虫，而不仅仅是队列+爬虫；要集成分布式任务、分布式事务等等，后续由于工作繁忙也渐渐的都放下了。目前任然是一个小巧、灵活、健壮、可观测的爬虫框架。 ultraman-rpc (一个练手的RPC项目) 单纯练手项目，实现了基于接口的 RPC 调用。 fas-cloud （faas 平台） 云，是一个很迷人的概念。曾经我也立志在云上创出一片天。但是最终还是没有完成。 整体项目完成了 50% 左右，做了 Function 函数管理功能、Function模板管理功能、Function 执行以及动态管理功能，很遗憾没有做完，...

在构建基于 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....

静态博客的出现，革了后端的命，极大的简化了搭建环节。但是与此同时，在写作方式上，更加依赖第三方编辑器，能否找到一个合适的编辑器成了大多数人能否坚持使用下去的源动力。本文基于 Hugo 静态博客推荐个人认为最优的编辑器 Obsidian。 Obsidian 是一款非常优秀的双链笔记编辑器。其最主要亮点功能是通过双链构建知识网络。具有完备的编辑器、强大的命令工具以及众多优秀的插件。 关于 Obsidian 的相关配置方案可以参考上一篇文章《 Hugo 博客写作最佳实践 》，在文章中，介绍了如何通过 QuickAdd 插件快速创建一篇博文，以及如何快速编写发布文章，其中还包括如何进行静态资源同步上传图床以及外链回写的实现。 本文主要介绍在实现上文的工作流的基础上，一些写作最佳实践。 1.美观 写作是一个长期的行为，在写作过程中需要一直面对编辑器进行构思，编写，排版，调整。所以，一个符合个人审美的编辑器尤为重要。 Obsidian 编辑器本身作为一个颜值在线的编辑器，已经具备了很高的颜值起点。而且如果对官方主题不满意的话，可以在设置中的外观菜单项里打开主题管理功能，在主题社区中选择符合个人需求的主题进行替换。 除此之外，我们还可以通过自定义 CSS 代码片段对部分展示效果进行调整。这里提供修改编辑器字体的样例。 在外观选项中点击文件夹图标打开 CSS 代码片段目录 在打开的目录中新建文件 字体修改.css 并在文件中输入如下内容。 .view-content div.cm-line,.cm-string { font-family: "仿宋" !important; } .markdown-preview-section { font-family: "仿宋" !important; } 效果如下： 2.方便 基于当前的工作流程，在 Obsidian 中我们已经可以完成从创建到编写到发布所有工作。但是这还不够，既然使用了 Obsidian，我们虽然没办法使用其丰富的 markdown 语法。但是不耽误享受其丰富的插件系统带来的种种便利。 这里推荐另外两个插件 homepage 和 dataview homepage 允许 Obsidian 在打开之后显示默认笔记页面作为仪表面板 dataview 是 Obsidian 众多插件中，构建索引的王者。 通过 homepage ，可以设定一个页面作为 Obsidian 打开之后的默认主仪表面板。在上篇文章中，创建了 obs_scripts 目录用来存储创建文章的脚本。本文复用该目录，在其中创建一篇名叫 主面板 的笔记。...

如今，如果你仅仅为了更好的分享或者记录东西，想做一个博客；静态博客几乎是最好的选择。不需要太多的技术含量，网上有大把的教程，不需要花钱买服务器，甚至不需要花钱买域名。 这篇文章是在使用 hugo 将博客搭建起来的基础上，摸索出来的一套写作流程。可有最大程度上简化除了写作之外的流程。 🏖️前提 这篇文章的前提是你已经通过 hugo 和 github 搭建起来一个可以访问的 Github Pages 主页。如果尚未完成这个步骤，建议通过其他教程先做到这一步。 🤣当前痛点 在当前的流程中，假如你需要新建一篇文章并发布，大体流程如下： 打开命令行工具，切换到博客目录下，执行 hugo new posts/newarticle.md 创建一个新页面 构思编写文章，如果中途需要贴图片，需要先将图片拷贝到指定静态资源目录下或者上传到图床并复制外链到剪贴板，然后在文章中通过图片引入语法添加图片。 文章写完之后，再次打开命令行工具，切换到博客目录下，执行 hugo -D 编译静态网站文件。 通过 git 命令行或者图形话工具，将更新上传至 Github 仓库中。完成！ 以上便是发布一篇文章的基础工作，其中最麻烦便是图片资源的管理以及来回切换工具操作。 ☝️如何解决 1. 自动编译 首要解决的问题是如何才能不需要每次手动编译之后再上传。这也是最好解决的部分。我们可以搭配 Github Actions 使仓库在更新的时候自动编译部署。 Github Actions 是 Github 提供的一套持续集成服务。 操作流程： 在仓库的根目录新建 .github/workfolws 目录 在 .gitub/workflows 目录中新建流程配置文件 main.yml 在 main.yml 中配置每当监听到仓库提交更新，就触发编译，并将编译后的静态网页部署在 gh-pages 分支。 文件目录如下： 配置内容如下： name: blog deploy pipline on: push: tags: - '*' branches: [ main ] env: REGISTRY: ghcr....