学习实战记录

if-else 优化的折中思考：不是消灭分支，而是控制风险 前言 各种社区里，你一定见过无数篇标题类似"彻底消灭 if-else"、"告别 if-else 地狱"的文章。这些文章通常会展示一段充满 i

泛型+函数式：让策略模式不再是复制粘贴地狱 导入模块的"复制粘贴地狱" 血泪史：每加一个导入类型，我都要复制200行代码 前段时间我写了一个会员导入模块 导入模块的设计架构图 目前已有的3个导入策略：

虽然java通过synchronized可以解决线程并发的同步的问题，同时也对synchronized进行了优化，提升了性能，但是它获取锁的操作是隐式获取的，所有很多时候我们没办法更加细粒度的控制，于

背景 业务上我们常会需要一些重试的场景，比如一些对推送成功率要求较高的场景，或者调用三方接口超时的场景等。自己编写一套通用的重试代码会比较繁琐，所以就可以选用guava-retrying实现灵活的重试

前言，我们讲了synchronized的作用和基础的原理，但是我们会发现，如果按照synchronized最开始的设计，他的效率是十分低下的，会显得十分鸡肋，所以在java1.6之后，对synchro

cas这个想必大家都不陌生，全名叫Compare And Swap，比较并交换，也可以理解是java的一个轻量级加锁的解决方案。 原理 从名字也能看出来他的基本原理，就是每次加锁前，会先将主内存的锁对

synchronized是java并发中解决同步问题的一个重量级方案，为什么是重量级方案呢，因为使用synchronized会发生对内核态和用户态切换的操作，简单来说就是会发生应用和操作系统之间的交互

Volatile是java并发中解决同步问题的一个轻量级方案，通过将变量声明为Volatile后，保证变量能被其他线程可见 原理 为什么Volatile可以保证其他线程可见呢？这得先从java的内存模

事件背景 安全内参9月29日消息，爱尔兰监管机构对Meta公司（Facebook母公司）处以1.01亿美元（约合人民币7.08亿元）的罚款，原因是Meta以明文形式存储了数亿用户密码，并允许公司内部员

背景 众所周知，java关于的ai应用的生态一直不是很好，对于ai模型的适配也不是便捷。虽然Spring AI出现帮助我们降低接入ai的成本，但是没有接入国内的相关的ai大模型，spring-ai-a

背景 为了提高插件的实用性，我们考虑加入代码的追加的功能，简单来讲，就是通过插件，去生成controller和service的层级代码，避免我们为了创建层级去来回切换，同时也是强制保持代码的规范。 实

背景 为了实现和公司数据库框架的结合，考虑再插件调用的时候，执行maven命令，为此查了不少资料，结果发现竟然这么简单。 实践 执行普通命令的时候，需要创建自定义一个RunnerAndConfigur

背景 还是为了开发脚手架，打算新增一个根据表字段生成代码的demo，后续再去结合我们项目用的数据库生成框架，可以更高效的开发，就考虑使用idea的databasetool插件，来获取表信息 实践 要调

背景 最近要开发一个基于idea插件的项目脚手架插件，市面上其实有很多类似的插件，但为了后续更多的定制化，所以还是考虑自己在搞一套。 大概的思路就是在idea的项目向导页面，新增一个tap，自定义路径

背景 书接上文，我们了解了xxl-job，admin端是如何发送消息到客户端，今天我们就来分析一下，客户端如何找到对应的jobhandler并执行的 源码解析 之前我们分析到，xxl-job会在客户端

背景 最近测试环境，有一个应用一直没法关闭，只能强杀，登上服务器发现是这个应用有个线程一直监听着9999端口，排查发现是xxl-job没有正确配置，导致线程一直等待，无法正常关闭，正确配置后就正常了。

背景 最近公司有一个播报打印的功能，需要上线，功能更是比较简单，就是根据不同的订单类型进行一个报文的组合，最后将报文推送到阿里云平台。细细思索一番，其实能感觉到，不论播报还是打印其实都是一个推送的行为

背景 最近项目因为有个同事错误的使用了FutureTask，导致线程池没有真的进行异步操作，使得线上接口报超时，差点产生线上事故 首先看一下同事的代码 目的想必大家都看的出来，就是支付成功后，执行异步

函数式接口实现分布式锁 背景 最近使用分布式锁比较多，发现大家使用分布式锁，都各有各的用法，想着用搞一个加锁模板，方便大家使用，就选择声明一个函数式接口，去实现加锁的模板 函数式接口 是一种特殊的接口

记录一次策略模式和组合模式的实践运用 背景 最近公司有一个支付路由的功能，大概的需求就是创建一个支付规则，支付规则里可以根据不同的情况，对我们支付通道进行一个切换，比如说我们看设置交易笔数，根据不同的