Accelerate Blog

关于我

Sun, 19 Jul 2026 00:00:00 +0000

你好，我是 Acclerate。

我是一名后端工程师。

写代码和旅行，是我过去几年生活里两件很重要的事情。

代码让我学会如何把复杂的问题拆开、想清楚，再一点点解决；而走过不同的城市，也让我明白，很多事情不一定需要一个标准答案，有些经历本身就是答案。

我喜欢记录这些东西。

这里有我写过的代码、解决过的问题，也有我在不同城市生活时看到的风景和留下的一些思考。

写代码的日子

我从 2019 年开始成为一名 Java 后端工程师。

第一份工作是在武汉一家传统零售企业。那几年，零售行业正在经历数字化转型，我参与了传统业务系统向云端迁移和升级的过程。

那时候每天面对的是很多看起来并不起眼的事情：

商品库存怎么准确同步？

价格变化怎么及时传递？

成千上万种商品的信息，如何在不同系统之间保持一致？

后来我慢慢理解，所谓"工程"，很多时候并不是创造一个多么炫酷的新东西，而是把那些容易出错、没人愿意反复处理的小问题解决好，让系统更稳定，让使用它的人少一些麻烦。

后来，我进入一家长期服务软件行业的公司，参与医保相关系统建设。

这五年里，我跟随着项目去过南昌、杭州、海南、烟台。

医保系统和普通互联网应用有一点不同。

它连接的不只是数据和程序，而是真实生活中的人。

一次医疗结算、一笔费用记录、一次跨系统的数据同步，背后可能对应着某位患者的一次就医经历。

所以我一直觉得，代码虽然只是工具，但工具背后的事情值得认真对待。

这些年，我主要做过几类工作：

让大量业务数据能够安全、准确地在不同系统之间流转；
让面对高压力访问的服务能够保持稳定，即使出现异常，也能尽可能恢复；
帮助团队建立更可靠的数据处理流程，让错误尽可能提前被发现；
把自己踩过的坑记录下来，让后来的人少走一些弯路。

这些事情可能不会出现在某个耀眼的宣传页面里，但它们组成了一个工程师每天真实的工作。

把事情做好，把系统维护好，让别人使用起来更安心，这也是我理解的工程价值。

走路的日子

工作让我去了很多城市。

后来我发现，每一个项目所在地，都不只是地图上的一个坐标，而是一段真实生活。

南昌

南昌的夏天很闷热。

2021 年，我第一次长期驻场在那里。工作之外，我喜欢去赣江边走走。

晚上江风吹过来，远处红谷滩的灯光亮起来。

那时候刚进入新的阶段，面对新的项目和新的环境，其实也有很多迷茫。

但很多事情就是这样，走着走着，就慢慢找到了方向。

杭州

杭州给我的感觉一直很特别。

我去过很多次西湖，但最喜欢的是清晨的苏堤。

天刚亮的时候，人很少，湖面安静，柳树随着风轻轻摆动。

那几年，我参与了大规模数据处理和业务结算相关工作。

有时候凌晨还在处理系统问题，有时候清晨又去湖边散步。

写代码和看风景，好像成了两种不同方式的思考。

海南

海南的项目在海口。

工作之外，我喜欢骑车去海边。

假日海滩的风很大，椰子树常常被吹得倾斜，但依然在那里生长。

那段时间，我主要负责数据治理相关工作。

简单来说，就是帮助系统识别和处理那些"不完美的数据"。

现实世界里的数据，就像现实生活一样，很难做到完全整洁。

重要的是建立好的规则和机制，让系统能够理解它、修正它。

烟台

烟台停留的时间最长，留下的记忆也很深。

项目上线后，经常沿着海边散步。

夕阳落在渤海上的时候，会觉得一天的忙碌突然变得很遥远。

在那里，我整理了一些关于系统数仓设计的文档，例如如如何给数仓分层、如何洗数据、如何做好可视化。

后续这些内容也被整理发布到了博客里。

这些城市对我来说，并不是简单的"出差地点"。

它们记录了我职业成长中的不同阶段，也留下了一些属于自己的生活片段。

代码可以修改、项目可以结束，但那些经历会一直留在记忆里。

关于这个博客

建立这个博客，是因为我想把一些真正理解过、实践过的东西记录下来。

平时写东西的地方很多，而这里更像是一个公开的笔记本。

我希望它不仅能帮助自己回顾，也能给偶然来到这里的人提供一些参考。

使用CloudFlare部署GitHub仓库里的静态项目

Sat, 18 Jul 2026 22:37:57 +0800

先登录 CloudFlare

进入 Workers & Pages 管理页, 点击 Create a Worker

关联 GitHub 账户, 然后进入部署配置页

我们的项目托管在GitHub，所以选择 Import an existing Git repository

选择账户和仓库，然后点击 Begin setup

输入域名、选择分支、选择部署方式，然后点击 Save and Deploy

它就会自动部署，部署完成后，就可以在浏览器访问了

等待几分钟，就可以在浏览器访问了 https://sod-momas.pages.dev/ ，甚至自带https

怎么在 Windows 下查所有运行任务和端口

Sat, 18 Jul 2026 00:00:00 +0000

在排查端口占用、定位异常进程或检查服务状态时，我们经常需要查看本机正在运行的任务以及它们占用的网络端口。本文整理了 Windows 下最常用、最实用的几条命令。

一、查看所有运行中的任务

使用 tasklist 可以列出当前系统中所有正在运行的进程：

tasklist

如需按名称过滤，比如只看包含 java 的进程：

tasklist | findstr java

提示： findstr 类似 Linux 下的 grep，用于按关键字过滤输出。

二、查看所有端口与对应进程

使用 netstat 可以查看所有网络连接和监听端口，-ano 参数分别表示：显示所有连接、不解析名称、显示 PID。

netstat -ano

各列含义：

列	含义
Proto	协议（TCP / UDP）
Local Address	本地地址与端口
Foreign Address	远端地址与端口
State	连接状态（LISTENING、ESTABLISHED 等）
PID	占用该连接的进程 ID

三、根据端口反查进程

想知道某个端口（例如 8080）被哪个进程占用，直接用 findstr 过滤：

netstat -ano | findstr :8080

输出结果最后一列的 PID 就是目标进程。例如得到 PID 为 1234。

四、根据 PID 查任务详情

拿到 PID 后，再用 tasklist 精确查询该进程的名称：

tasklist | findstr 1234

更直接的办法

也可以一步定位端口对应的进程名：

for /f "tokens=5" %a in ('netstat -ano ^| findstr :8080') do tasklist | findstr %a

五、结束指定任务

确认进程可以关闭后，使用 taskkill 结束它。按 PID 结束：

Nginx 配置

Sat, 11 Jul 2026 15:12:43 +0000

SSL证书

server {
    listen              443 ssl;
    server_name         web.guosen.com.cn;
    ssl_certificate     /usr/local/sdata/nginx/ssl/web.guosen.com.cn.cer;
    ssl_certificate_key /usr/local/sdata/nginx/ssl/web.guosen.com.cn.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:1m;
    ssl_session_timeout 5m;
    ssl_prefer_server_ciphers on;
}

直接返回内容

  location = /abc/.wel-know {
        default_type text/plain;
        return 200 'testbbbbbbbbbbbbbbbbbbbbbbbb';
    }

这样在访问 /abc/.wel-know 的时候就会直接返回 testbbbbbbbbbbbbbbbbbbbbbbbb了, 可以用来SSL验证

nginx配置返回文本或json

Nginx动静分离配置

server {
    listen       80;
    # 监听的域名
    server_name  local.momas.cc;
    # /index.html -> /
    if ($request_uri ~* "^(.*/)index\.html$") {
        return 301 $1;
    }
    # 首页
    location = / {
        root html/local.momas.cc;
    }
    # 静态资源文件夹
    location ^~ /static {
        root html/static;
    }
    # 拦截静态资源文件
    location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|js|css)$ {
    root html/local.momas.cc;
    }
    # 虚拟主机1,使用指定url匹配
    location /vhost1 {
        proxy_pass http://localhost:8080;
    }
    # 虚拟主机2,使用指定url匹配
    location /vhost2 {
        proxy_pass http://localhost:7070;
    }
}
# 拒绝所有异常地址访问,例如ip地址直接访问
server {
    listen       80 default_server;
    server_name  _;
    location / {
        return 404;
    }
}

可能有用的配置

Lock4j + Redis基于 Redis 的 AP 特性来实现分布式锁

Fri, 10 Jul 2026 15:05:10 +0000

`@Lock4j` 方法级分布式锁注解

Lock4j 「注解属性 → key 生成规则 → 典型用法 → 底层大致流程」来解析这份 @Lock4j 源码。

1. 整体作用

**@Lock4j**** 是一个方法级分布式锁注解，基于 Spring AOP 实现。标注在方法上后，调用方法时会：**

先根据 **name** + **keys**（SpEL）生成锁 key；
通过 **executor**（Redis / Redisson / Zookeeper 等）尝试获取锁；
获取成功 → 执行方法；失败 → 根据 **failStrategy** 处理；
方法执行完（包括抛异常）后，根据 **autoRelease** 决定是否自动释放锁，或等 **expire** 到期自动释放。

2. 注解元信息

@Target(value = {ElementType.METHOD})
@Retention(value = RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Lock4j {
    ...
}

**@Target(ElementType.METHOD)**：只能加在方法上。
**@Retention(RUNTIME)**：运行时保留，AOP 通过反射读取。
**@Inherited**：对类继承有效（实际使用中主要看方法是否被代理）。
**@Documented**：生成 javadoc 时会显示该注解。

3. 属性逐条解析

3.1 `name`：锁资源名称（前缀）

String name() default "";

作用：作为锁 key 的固定前缀，用于区分业务模块或资源类型。
为空时：默认会使用 **包名+类名+方法名** 作为前缀（由 **DefaultLockKeyBuilder** 实现）。
典型用法：

@Lock4j(name = "order:")
public void processOrder(...) { }

3.2 `executor`：锁执行器类型

Class<? extends LockExecutor> executor() default LockExecutor.class;

指定底层锁实现：RedisTemplate、Redisson、Zookeeper 等。
默认 **LockExecutor.class**：由 Spring Boot Starter 根据依赖自动选择（优先级通常为 Redisson > RedisTemplate > Zookeeper）。
一般情况下不用管，只有在多实现混用时，需要方法级强制指定某个 **executor**。

3.3 `keys`：动态 key 部分（SpEL）

String[] keys() default "";

支持 SpEL 表达式，用于从方法参数中取值，组成动态 key。
最终锁 key 的构成逻辑（默认 **DefaultLockKeyBuilder**）：
- 前缀：**lock4j:****（可全局配置） + ****name**
- 中间：**包名+类名+方法名**（如果 **name** 为空）
- 后缀：**keys**** 中每个表达式解析后拼接**
示例：

@Lock4j(name = "order:",
        keys = {"#userId", "#orderId"},
        expire = 30000)
public void processOrder(Long userId, String orderId) { }

可能生成类似 key：**
****lock4j:order:com.example.OrderService:processOrder:123:ORD001**

微服务模块化结构规范（Spring Cloud + Gradle）

Mon, 06 Jul 2026 14:37:11 +0000

微服务模块化结构规范（Spring Cloud + Gradle）

一、模块划分与职责

每个微服务按功能拆分为五个核心模块：

模块	模块名	职责	典型内容
公共模块	`${module}-common`	定义公共常量、实体、工具类、方法执行时间监控等	- util、Page、PageReq
契约模块	`${module}-contract`	定义对外服务的业务接口和传输对象（DTO），供内部实现和外部客户端共享；	- 业务接口（如：OrderService） - 响应（如：OrderDTO） - 服务间请求DTO（如：OrderQueryDTO，无校验） - 枚举、常量等；
业务实现模块	`${module}-biz`	实现业务逻辑，包含数据访问、基础服务、聚合服务；	- Entity、Mapper、基础Service、聚合Service（实现contract模块中的接口）、内部转换器（Entity -> DTO） - 前端专用Request（带@Valid或者@Validated校验）、VO
应用启动模块	`${module}-host`	Spring Boot应用入口，提供REST API，处理与前端或者其他微服务间交互；	- 两类Controller 1、内部Controller（/api/internal，返回DTO） 2、前端Controller（/api，返回VO） - 转换器（Request -> DTO -> VO） - 启动类
客户端模块	`${module}-client`	封装feign客户端，供其他微服务调用；	- Feign接口（指向host中的内部Controller） - 服务间请求Request（带校验） - Feign配置 - 依赖client

二、模块依赖关系

contract模块：无任何依赖；
biz模块：依赖contract模块，实现其接口；
host模块：依赖biz和client模块，使用业务服务和客户端的请求对象；
client模块：依赖contract模块，使用其DTO；

关键点：

Important

时间戳防重放机制深度解析

Mon, 06 Jul 2026 14:37:06 +0000

由浅入深地为您剖析“时间戳防重放”机制，结合您提供的 `PayRsaSignService` 代码进行深度解析。

一、本质：给请求贴一张“过期日期”

核心概念：
时间戳防重放的本质，是为每一次网络请求赋予一个**“生命周期”**。
通俗类比：
想象您去银行取钱。

签名：相当于您的身份证，证明“我是我”。
时间戳：相当于存折或支票上的签发日期。
如果有人捡到了您昨天取钱的支票（截获了昨天的请求），即使他能完美伪造您的签名（签名验证通过），银行柜员一看日期是昨天的，也会拒绝兑现。因为这张票据已经“过期”了。
在数字世界中，时间戳确保了：“即使签名正确，请求也不能是‘老掉牙’的旧数据。”

二、形成原因：为什么光有签名还不够？

很多开发者会误以为：“我用了 RSA 非对称加密签名，数据很安全，为什么还要加时间戳？”
根本原因在于：签名只能保证“完整性”和“身份认证”，无法保证“时效性”。

中间人攻击的局限性：
虽然 HTTPS 加密传输，但在某些极端情况下（如客户端中毒、代理服务器被劫持、局域网监听），黑客可能截获了一个合法的请求包。
- 该请求包：Method=POST, URL=/pay, Body=转账100元, Sign=xxxxx。
- 由于签名是针对内容计算的，黑客即使不解密，只要原样发送这个包，服务器就会认为是一次合法的请求。
重放攻击：
黑客不需要破解密码，只需要做一个“复读机”。
- 你给老婆转账 100 元，黑客截获了这个请求。
- 黑客把你这个请求原封不动向服务器发送 100 次。
- 结果：你损失了 1 万元。
  引入时间戳的原因：为了让服务器能区分“这是用户刚刚发出的请求”还是“黑客复制的旧请求”。

三、现象：如果不防重放会发生什么？

如果不加时间戳校验，系统会出现极其诡异的现象：

重复扣款/发货：
用户只点了一次“支付”，后台却收到了多次扣款通知，导致余额异常减少。
数据洪水：
黑客可以截获一个“查询用户列表”的请求，然后编写脚本疯狂重放。虽然每次查询都合法，但数据库会被这种高并发查询压垮，导致服务瘫痪。
逻辑漏洞：
某些业务逻辑如果缺乏幂等性设计，重放可能导致账号状态混乱（如优惠券被重复使用）。

四、核心处理办法（结合代码深度讲解）

在您的代码中，处理逻辑集中在 signatureVerify 方法的前半部分。核心办法分为三步：“取时间”、“算差值”、“判生死”。

1. 取时间：客户端与服务端对表

String timestamp = request.getHeaders().getFirst(X_PAY_TIMESTAMP);
// ...
long ts = Long.parseLong(timestamp);
long now = Instant.now().getEpochSecond();

客户端：发送请求时，在 Header 里带上当前的 Unix 时间戳（秒或毫秒）。
服务端：收到请求时，立即获取服务器当前时间 now。
关键点：这个时间戳是参与签名计算的（代码后半部分的 signString 包含了 timestamp）。
- 这意味着黑客不能随意修改时间戳。如果黑客把旧请求的时间戳改成当前时间，签名就会对不上，验签直接失败。

2. 算差值：容忍网络延迟

private static final long TIMESTAMP_TOLERANCE_SECONDS = 300L; // 5分钟容忍度
// ...
if (Math.abs(now - ts) > TIMESTAMP_TOLERANCE_SECONDS) {
    // 拒绝请求
}

这里最核心的设计是 Math.abs(now - ts) 和 容忍度。
深度解析：为什么要用绝对值 Math.abs？
这处理了两种异常情况：

挂载自定义 JAR 导致 Pod 漂移到其他 Node 的深层次原因分析

Mon, 06 Jul 2026 14:37:01 +0000

shenyu挂载自定义 JAR 导致 Pod 漂移到其他 Node 的深层次原因分析

适用场景说明：本文第二~四章描述的 “Pod 漂移” 是 Kubernetes 场景的理论分析与迁移预案。
当前 ShenYu 网关运行在 Docker Compose（单机） 环境：

无 Cgroup 内存限制（宿主机 23.47GiB，bootstrap 实际仅用 1.05GiB / 4.49%）

无 K8s 调度器，容器固定在本机，重启后必然还在本机，不可能漂移到其他 Node

ext-lib 通过本地 bind mount（./shenyu-bootstrap/ext-lib:/opt/shenyu-bootstrap/ext-lib），不存在 PVC 拓扑问题

因此当前环境下挂载 shenyu-sign-gateway-spi-2.6.1.jar（8.9KB）不会触发本文所述的任何漂移。
本文价值在于：当未来把 ShenYu 网关迁移到 K8s 集群时，ext-lib 自定义 JAR 的挂载方式需要按第五章方案重新设计，否则可能触发 OOMKilled / 存储拓扑冲突 / 启动崩溃等问题。

文档结构

章节	内容	适用时机
一	K8s Pod 漂移机制（核心概念）	迁移到 K8s 前必读
二	4 条漂移原因链（OOM/存储/Init容器/安全）	K8s 排障参考
三	排查四步法	K8s 故障定位
四	通用防御方案	K8s 资源配置
五	ShenYu ext-lib 迁移 K8s 实操方案（本文重点）	迁移时直接套用

一、核心概念纠偏：Pod 为什么会"漂移"？

首先需要明确：Kubernetes 本身不会主动"移动"一个正在运行的 Pod。Pod 是 K8s 的最小调度单元，一旦绑定到某个 Node，其生命周期就固定在该 Node 上。

sign-plugin-验证手册

Mon, 06 Jul 2026 14:36:56 +0000

ShenYu 加签验签验证手册（SignPlugin × RequestPlugin × DividePlugin）

适用版本：ShenYu admin/bootstrap 2.6.x ~ 2.7.x（网关侧），客户端侧基于本仓库 shenyu-client-core 的 sign 包。
协议基准：支付服务（微信支付 V3 风格）—— RSA-SHA256 非对称签名。

本手册与 divide-plugin-验证手册.md 配套：divide 关注"转发"，本手册关注"安全"。

一、需求背景与协议总览

1.1 什么时候需要加签与验签

业务系统调用支付接口时，双方需基于非对称密钥互相验证身份与报文完整性，并防止重放。
每个参与方各持有一对 RSA 密钥（自己的私钥 + 自己的公钥），并把自己的公钥交给对方保管：

参与方	自己持有（用于加签）	保管对方的（用于验签）
业务系统（BIZ）	业务系统私钥	支付服务公钥
支付服务（PAY）	支付服务私钥	业务系统公钥

关键原则：私钥永不离开持有方，只在本地加签时使用；公钥交给对方，对方用来验签。

一次完整交易是串联的两段（不是三个独立场景），时序如下：

请求段（BIZ → PAY）：业务系统发起支付请求，用【业务系统私钥】对请求加签生成 sign；
支付服务收到后用【业务系统公钥】验签。验签通过后才会处理业务。
响应段（PAY → BIZ）：支付服务处理完业务，用【支付服务私钥】对响应数据加签生成 sign，连同响应一起返回；
业务系统收到后用【支付服务公钥】验签响应。
回调段（PAY → BIZ，可选，异步）：支付服务在交易状态变化时，用【支付服务私钥】对回调通知加签，
POST 给业务系统的回调地址；业务系统用【支付服务公钥】验签。验签逻辑与响应段一致。

场景	加签方	加签所用私钥	验签方	验签所用公钥
请求（BIZ→PAY）	业务系统	业务系统私钥	支付服务	业务系统公钥
响应（PAY→BIZ）	支付服务	支付服务私钥	业务系统	支付服务公钥
回调通知（PAY→BIZ）	支付服务	支付服务私钥	业务系统	支付服务公钥

1.2 协议要素（本仓库 `shenyu-client-core` 的 `sign` 包已实现）

要素	约定
传输	HTTPS（请求时不忽略证书校验）
数据格式	JSON（UTF-8），`Content-Type: application/json; charset=utf-8`
签名算法	`SHA256withRSA`（标准 JCA，JDK8 原生支持）
加签结果	Base64 编码字符串
HTTP 头	`X-Pay-Timestamp`（秒级）/ `X-Pay-Nonce`（32位hex）/ `X-Pay-Sign`（签名值）

1.3 待签名串格式

请求加签（5 行格式，每行 \n 结尾，含最后一行）：

ShenYu 网关注册接入 — 改动总结

Mon, 06 Jul 2026 14:36:51 +0000

✅ ShenYu 网关注册接入 — 改动总结

已在分支 feature/shenyu-register(基于 feature/0830)完成全部改动，并通过实测验证注册成功。

一、核心目标

将 erpm-pay-center 作为 ShenYu client，启动时把 HTTP 接口元数据上报到 shenyu-admin(本地 Docker apache/shenyu-admin:2.7.0.3)，由 divide 插件统一转发外部流量。

二、关键决策（踩坑后定稿）

决策点	结论	依据
ShenYu client 版本	`2.6.1`	2.7.x 需 SB3+JDK17，本项目 SB 2.3.12+JDK11 不兼容；2.6.1 兼容 SB2.x，且实测能成功注册到 2.7.0.3 admin
配置结构	两层分离：`shenyu.register.` + `shenyu.client.http.props.`	单层 `shenyu.client.registerType` 会导致 `registerType=null` → NPE
本地禁用机制	`spring.autoconfigure.exclude`（2.6.1 无 `enabled` 开关）	反编译 2.6.1 确认 `ShenyuClientCommonBeanConfiguration` 无 `@ConditionalOnProperty`
profile 设计	两个互斥本地 profile（local / regtest）	实测 `exclude` 是覆盖语义，不能跨 profile 叠加

三、改动文件清单（本次新增/修改，共 7 处）

依赖层（2 处）

文件	改动
`config.gradle`	新增 `'shenyu': '2.6.1'` 版本变量
`pay-host/build.gradle`	新增 `shenyu-spring-boot-starter-client-springmvc:2.6.1` 依赖

代码层（4 处，4 个 Controller 加注解）

文件	注解
`PayController.java`	`@ShenyuSpringMvcClient(path = "/v1/pay/**", desc = "支付接口")`
`RefundController.java`	`@ShenyuSpringMvcClient(path = "/v1/refund/**", desc = "退款接口")`
`CollectionClaimController.java`	`@ShenyuSpringMvcClient(path = "/api/v1/collectionClaim/**", desc = "收款认领接口")`
`ElectronicReceiptController.java`	`@ShenyuSpringMvcClient(path = "/api/v1/electronicReceipt/**", desc = "电子收据接口")`

CallbackDemoController 按计划未加注解，不注册。

MapStruct 语法和技术点说明及最小用例

Mon, 06 Jul 2026 14:36:46 +0000

一、 MapStruct 语法和技术点说明及最小用例

这段代码中主要用到了以下 5 个 MapStruct 的核心特性：

1. `@Mapper` 注解与 `componentModel`

说明：componentModel = "spring" 会让 MapStruct 生成的实现类带上 @Component 注解，从而可以被 Spring 容器管理并依赖注入。
最小用例：

// 源
public class UserDTO { private String name; }
// 目标
public class UserVO { private String name; }
// 定义 Mapper
@Mapper(componentModel = "spring")
public interface UserMapper {
    UserVO toVO(UserDTO dto);
}
// 生成的实现类大概长这样：
// @Component
// public class UserMapperImpl implements UserMapper { ... }

2. 多源参数映射

说明：MapStruct 支持在一个方法中传入多个源对象，并通过 参数名.属性名 的方式指定映射来源。
最小用例：

divide-plugin-验证手册

Mon, 06 Jul 2026 14:36:41 +0000

ShenYu 2.6.1 divide 插件功能验证手册

环境

组件	地址	版本
shenyu-admin (Docker)	`localhost:9096`	2.6.1
shenyu-bootstrap (Docker)	`localhost:9196`	2.6.1
demo (IDEA 多实例)	`10.19.236.150:8179` / `:8189`	Spring Boot 2.7.18
demo contextPath	`/http-demo11`	—

Apache ShenYu Divide 插件深度解析

Divide 插件是 Apache ShenYu 网关体系中最核心、最基础的 HTTP 反向代理插件，是所有 HTTP 流量转发的基石，对应传统网关的「路由转发 + 负载均衡」核心能力，同时承载了流量治理、超时管控、故障重试等进阶能力。以下从入门认知、核心功能、底层原理、生产实践四个层级逐层拆解。

一、入门层：核心定位与架构位置

1. 插件定位

Divide 插件是专门用于处理 HTTP 协议请求的代理插件，是 ShenYu 网关数据面的「流量分发执行器」。所有 HTTP 请求经过鉴权、限流、熔断等前置治理插件后，最终都会进入 Divide 插件完成路由选择与转发参数组装，再交由底层 HTTP 客户端发往后端服务。

2. 在插件链中的位置

ShenYu 采用责任链模式组织插件，Divide 属于代理类末端插件：

前置插件：GlobalPlugin（全局上下文解析）、SignPlugin（鉴权）、RateLimiterPlugin（限流）、HystrixPlugin（熔断）等治理类插件
核心位置：Divide 插件负责匹配路由规则、选定上游节点、设置转发参数
后置执行：由底层响应式 HTTP 客户端（基于 Spring WebFlux WebClient）完成真正的请求转发与响应回流

3. 核心价值

对比 Nginx 等传统反向代理，Divide 插件的核心优势是全动态化、插件化、细粒度管控：

maven&gradle

Mon, 06 Jul 2026 14:34:06 +0000

好问题。先直接回答第一个,再详细展开 Maven 与 Gradle 在 Spring Boot 下的差异。

一、bootRun 是不是推荐方式?

结论:bootRun 是 Gradle 下 Spring Boot 官方提供的"开发期运行任务",属于推荐方式之一,但不是唯一、也不总是最优的方式。

bootRun 本质

它由 org.springframework.boot Gradle 插件提供,底层做的是:

编译 main 源集 + 处理资源
用 Gradle 自己解析出的完整运行时 classpath
在一个子进程里执行主类的 main()(fork,不占用 Gradle Daemon)
把子进程的 stdout/stderr 接到 Gradle 控制台

// 等价于在干这些
gradle classes      // 1. 编译
java -cp <完整classpath> com.jzt.message.ErpmMessageStartServer  // 2+3. 运行

三种开发期运行方式对比(你的项目场景)

方式	启动速度	断点调试	改代码后热重载	命令行过长(Windows)	适用场景
IDEA 直接 Run 主类	⚡最快	✅ 原生	✅ devtools	❌ 易触发(你遇到的)	日常迭代、调试
bootRun	🐢 较慢(过 Gradle Daemon)	⚠️ 需额外配 `--debug-jvm`	✅ devtools	✅ 不触发	快速验证、CI、避免长 classpath
java -jar (bootJar)	🐢 最慢(要先打 fat jar)	⚠️ 麻烦	❌	✅	生产部署、集成测试

bootRun 的优缺点

优点

win查看所有端口和PID

Wed, 26 Jul 2023 10:01:22 +0000

控制台最后会显示Application启动失败，如下：

...
 
***************************
APPLICATION FAILED TO START
***************************
 
Description:
 
The Tomcat connector configured to listen on port 8080 failed to start. The port may already be in use or the connector may be misconfigured.
 
...

打开cmd命令窗口输入如下指令查看所有端口和PID

netstat -ano

2. 找到对应的端口对应的PID ，输入指令找到对应的进程

tasklist | findstr "4044"

3.杀掉该进程，再次启动就OK啦

taskkill /f /t /im java.exe

Spring使用@Transactional 管理事务，Java事务详解。

Mon, 24 Jul 2023 16:03:04 +0000

Spring使用@Transactional 管理事务，Java事务详解。

一、什么是事务

简单来说事务就是一组对数据库的操作要么都成功，要么都失败。事务要保证可靠性，必须具备四个特性：ACID。

A：原子性：事务是一个原子操作单元，要么完全执行，要么完全不执行。事务中的所有操作要么全部成功，要么全部失败，没有中间状态。

C：一致性：事务在执行前和执行后都必须保持数据库的一致性状态。

I：隔离性：事务的隔离性确保并发执行的事务彼此不会相互干扰。

D：一致性：一旦事务提交，其结果应该是永久性的，即使在系统故障的情况下也是如此。

二、什么是声明事务，什么是编程事务

声明事务

声明式事务是通过配置的方式来管理事务的行为，声明式事务的好处是可以将事务管理与业务逻辑相分离，提高了代码的可读性和维护性。

编程事务

编程式事务是通过编写代码显式地管理事务的开始、提交和回滚。使用编程式事务可以更加灵活地控制事务的细节，但需要更多的代码来处理事务管理，可能导致代码的冗余和增加了复杂性。

三、Spring 如何实现声明事务和编程事务的

声明事务

声明事务的代码很简单，我们也是经常使用的。

`java import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; @Service public class UserService { @Transactional public void performTransaction() { // 事务逻辑 } }`

编程事务

编程事务，需要自己来控制事务的流程，更加灵活但也更加复杂，一般不建议使用。（实际上我也没在生产环境中用过）

java import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.transaction.TransactionStatus; import org.springframework.transaction.support.TransactionCallbackWithoutResult; import org.springframework.transaction.support.TransactionTemplate;  @Service public class TransactionService {      private final TransactionTemplate transactionTemplate;      @Autowired     public TransactionService(TransactionTemplate transactionTemplate) {         this.transactionTemplate = transactionTemplate;     }      public void performTransaction() {         transactionTemplate.execute(new TransactionCallbackWithoutResult() {             protected void doInTransactionWithoutResult(TransactionStatus status) {                 try {                     // 事务逻辑                 } catch (Exception e) {                     status.setRollbackOnly();                     throw e;                 }             }         });     } }

四、声明事务是怎么实现的

Java线上排查问题工具——Arthas

Mon, 24 Jul 2023 16:02:46 +0000

Java线上排查问题工具——Arthas

Java线上问题排查工具—arthas_哔哩哔哩_bilibili

https://arthas.aliyun.com/doc/

一、安装

| Shellcurl -O https://arthas.aliyun.com/arthas-boot.jar java -jar arthas-boot.jar curl -L https://arthas.aliyun.com/install.sh | sh | | :— |

二、场景

2-1、查看当前服务运行的参数 JVM、内存、启动参数等

1、memory

查看当前堆和非堆的内存使用情况

2、thread

Shell# 查看全部的线程状态 thread # 查看当前最忙的 n个线程 thread -n # 查看被阻塞的线程 thread -b

3、查看当前类的方法

Shellsm cn.data.process.api.ApiApplication

4、其它

cls 清空控制台

history 查看历史的命令

pwd 查看当前目录

quit 推出 arthas

reset重制所有的 arthas的增强操作

stop 关闭 Arthas 服务端，所有 Arthas 客户端全部退出。会重置掉所有做过的增强类,但是用 redefine 重加载的类内容不会被重置。

version 查看当前的 arthas 的版本

2-2、查看线上源码

Shell# 查看源码 jad cn.data.process.api.ApiApplication # 保存反编译的源码 jad –source-only com.example.demo.arthas.user.UserController > /UserController.java

2-3、修改线上源码

Spring事务源码解析

Mon, 24 Jul 2023 15:57:50 +0000

Spring事务源码解析

上一篇文章我们已经知道了Java中Spring的事务，尤其是声明事务，这篇文章我们来深入探讨一下Spring的声明事务是如何实现的。

首先Spring的声明事务是基于AOP实现的，说到AOP我们就要搞清楚两点：

何时何地基于什么规则生成的代理对象

生成了代理对象后，拦截器做了什么

Spring事务代码都在 spring-tx 下面，所以我们也是着重看这块的代码。

一、何时何地生成的代理对象

简单来说代理对象生成的过程：容器启动的时候会往容器中注入两个bean

一个 Advisor，它包含advice和pointcut

advice 就是一个拦截器，拦截到执行的方法后就去做事务处理。

pointcut 会拦截使用 @Transaction 的方法。

一个后置处理器，它是实现了BeanPostProcessor的bean，重写了postProcessAfterInitialization 方法，这个后置处理器会遍历容器中所有的bean ，判断当前容器里面有没有满足自己的Advisor，如果有就基于此生成代理对象。

1、事务的开始（EnableTransactionManagement）

在Spring的环境下，我们要开启一个新的东西，都会使用 @Enablexxx 注解，事务的开始我们使用的是 @EnableTransactionManagement ，它的位置如下：

java Javapackage org.springframework.transaction.annotation;  @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Import(TransactionManagementConfigurationSelector.class) public @interface EnableTransactionManagement {     boolean proxyTargetClass() default false;         // 这里默认是 AdviceMode.PROXY 下面会用到    AdviceMode mode() default AdviceMode.PROXY;         // 优先级为最低    int order() default Ordered.LOWEST_PRECEDENCE; }

在上面的代码中使用了@Import，Spring运行的时候将会去运行这个注解中的类。

注：在SpringBoot环境下，它会被自动开启。（有兴趣可以自行研究为何自动开始）

2、向容器中注入Advisor和后置处理器（TransactionManagementConfigurationSelector）

通过继承关系，得知TransactionManagementConfigurationSelector本质上是一个ImportSelector，而ImportSelector是导入bean到Spring容器里面。

Javapublic class TransactionManagementConfigurationSelector extends AdviceModeImportSelector { @Override protected String[] selectImports(AdviceMode adviceMode) { // 通过上面的注解我们知道 adviceMode的默认值是 PROXY switch (adviceMode) { case PROXY: return new String[] {AutoProxyRegistrar.class.getName(), ProxyTransactionManagementConfiguration.class.getName()}; case ASPECTJ: return new String[] {determineTransactionAspectClass()}; default: return null; } } }

TransactionManagementConfigurationSelector 重写了导入的方法 selectImports 导入了两个类

HashMap

Thu, 06 Jul 2023 19:36:31 +0000

hashMap的长度

扩容机制

hashMap的数组，链表，红黑树转换过程

beanFactory注解

线程创建的核心线程数满了之后新增的线程是进队列还是

hashtable

crruterhashmap

Java内存溢出排查思路

Tue, 04 Jul 2023 23:37:38 +0000

当遇到内存溢出问题时，以下是一些常见的排查思路和步骤：

确认是否发生了内存溢出：首先，需要确认应用程序确实发生了内存溢出。可以通过观察系统日志、错误信息或者监控工具来确定。
分析堆转储快照（Heap Dump）：如果确认发生了内存溢出，可以使用工具生成堆转储快照，如jmap命令行工具或者可视化工具（如VisualVM）。然后，分析堆转储快照以了解哪些对象占用了大量内存，并找出可能的泄漏点。
检查代码中的潜在问题：检查代码中是否存在潜在的内存泄漏问题，例如未关闭的资源、长时间持有的引用等。特别注意对于缓存、集合、线程池等容器类的使用，确保正确释放资源。
观察GC日志：观察垃圾回收（GC）日志，了解GC的频率、停顿时间和内存回收情况。如果GC频繁且效果不佳，可能意味着存在内存泄漏或者配置不当的情况。
调整JVM参数：根据观察到的情况，调整JVM参数以优化内存使用。例如，增加堆大小、调整垃圾回收器的配置等。
使用内存分析工具：如果以上步骤无法解决问题，可以使用专业的内存分析工具来进一步深入排查。这些工具可以提供更详细的信息，帮助定位内存泄漏和性能瓶颈。
进行压力测试：在修复潜在问题后，进行压力测试以验证修复效果，并确保应用程序在高负载情况下不再发生内存溢出。

需要注意的是，内存溢出问题可能涉及多个因素，包括代码逻辑、资源管理、JVM参数配置等。因此，排查内存溢出问题通常需要结合多种方法和工具，并且需要有一定的经验和理解。

JVM内存区域划分、调优工具

JVM（Java虚拟机）内存区域划分是指将JVM的内存划分为不同的区域，用于存储不同类型的数据和对象。常见的JVM内存区域包括：

堆（Heap）：堆是JVM中最大的一块内存区域，用于存储对象实例。堆被所有线程共享，并且在JVM启动时创建。
方法区（Method Area）：方法区用于存储类信息、静态变量、常量等。它也被所有线程共享。
虚拟机栈（VM Stack）：每个线程都有一个独立的虚拟机栈，用于存储局部变量、方法参数、返回值等。每个方法在执行时都会创建一个栈帧，栈帧包含了方法的局部变量表、操作数栈等。
本地方法栈（Native Method Stack）：与虚拟机栈类似，但用于执行本地方法。
程序计数器（Program Counter Register）：程序计数器用于记录当前线程正在执行的字节码指令地址。

调优工具可以帮助开发人员识别和解决JVM内存相关的性能问题。以下是一些常用的JVM内存调优工具：

VisualVM：VisualVM是一个功能强大的可视化工具，可以监视和分析JVM的性能。它提供了堆、线程、GC等方面的实时数据，并且支持插件扩展。
JConsole：JConsole是一个基于图形界面的监控工具，可以监视JVM的内存使用情况、线程状态、垃圾回收等信息。
jstat：jstat是一个命令行工具，用于监视JVM的各种统计信息，如堆内存使用情况、GC统计等。
jmap：jmap是一个命令行工具，用于生成Java堆转储快照（heap dump），以便进行内存分析。
jvisualvm：jvisualvm是一个可视化工具，集成了VisualVM和其他插件，可以对JVM进行监视、调优和分析。

这些工具可以帮助开发人员识别内存泄漏、过度使用内存等问题，并提供相应的解决方案。但需要注意的是，正确使用这些工具需要一定的经验和理解JVM内存管理机制。

spring 事务失效

Tue, 04 Jul 2023 23:03:59 +0000

1.方法不是public修饰

2.方法所在的类没有被spring管理

3.方法抛出的异常没有被spring事务捕捉

4.方法被同类中的其他方法捕获

5.@Transactional()的propagation属性设置为PROPAGETION.NEVER

6.@Transactional()的rollbackFor设置的Exception类型不适配

更进一步，事务的本质是什么

Spring三级缓存详解

Tue, 04 Jul 2023 22:20:55 +0000

Spring三级缓存是为了解决对象间的循环依赖问题。

A依赖B，B依赖A，这就是一个简单的循环依赖。

我们来先看看三级缓存的源码。

（1）查看“获取Bean”的源码，注意getSingleton()方法。

public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
    //第1级缓存 用于存放 已经属性赋值、完成初始化的 单列BEAN
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    //第2级缓存 用于存在已经实例化，还未做代理属性赋值操作的 单例BEAN
    private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
    //第3级缓存 存储创建单例BEAN的工厂
    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
    //已经注册的单例池里的beanName
    private final Set<String> registeredSingletons = new LinkedHashSet<>(256);
    //正在创建中的beanName集合
    private final Set<String> singletonsCurrentlyInCreation =Collections.newSetFromMap(new ConcurrentHashMap<>(16));
    //缓存查找bean  如果第1级缓存没有，那么从第2级缓存获取。如果第2级缓存也没有，那么从第3级缓存创建，并放入第2级缓存。
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        Object singletonObject = this.singletonObjects.get(beanName); //第1级
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
                singletonObject = this.earlySingletonObjects.get(beanName); //第2级
                if (singletonObject == null && allowEarlyReference) {
                    //第3级缓存  在doCreateBean中创建了bean的实例后，封装ObjectFactory放入缓存的bean实例
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                        //创建未赋值的bean
                        singletonObject = singletonFactory.getObject();
                        //放入到第2级缓存
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        //从第3级缓存删除
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return singletonObject;
    }   
}

（2）“添加到第1级缓存”的源码：

线程池的核心参数以及运行原理

Tue, 04 Jul 2023 09:41:23 +0000

:::color1

java创建多线程有如下四种方式：

继承Thread类创建线程
实现Runnable接口创建线程（无返回值）
使用Callable和Future创建线程(有返回值)
使用线程池创建（使用java.util.concurrent.Executor接口）

:::

java多线程开发时，常常用到线程池技术，这篇文章是对创建java线程池时的七个参数的详细解释。

从源码中可以看出，线程池的构造函数有7个参数，分别是corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。下面会对这7个参数一一解释。

一、corePoolSize 线程池核心线程大小

线程池中会维护一个最小的线程数量，即使这些线程处理空闲状态，他们也不会被销毁，除非设置了allowCoreThreadTimeOut。这里的最小线程数量即是corePoolSize。任务提交到线程池后，首先会检查当前线程数是否达到了corePoolSize，如果没有达到的话，则会创建一个新线程来处理这个任务。

二、maximumPoolSize 线程池最大线程数量

当前线程数达到corePoolSize后，如果继续有任务被提交到线程池，会将任务缓存到工作队列（后面会介绍）中。如果队列也已满，则会去创建一个新线程来出来这个处理。线程池不会无限制的去创建新线程，它会有一个最大线程数量的限制，这个数量即由maximunPoolSize指定。

三、keepAliveTime 空闲线程存活时间

一个线程如果处于空闲状态，并且当前的线程数量大于corePoolSize，那么在指定时间后，这个空闲线程会被销毁，这里的指定时间由keepAliveTime来设定

四、unit 空闲线程存活时间单位

keepAliveTime的计量单位

五、workQueue 工作队列

新任务被提交后，会先进入到此工作队列中，任务调度时再从队列中取出任务。jdk中提供了四种工作队列：

①ArrayBlockingQueue

基于数组的有界阻塞队列，按FIFO排序。新任务进来后，会放到该队列的队尾，有界的数组可以防止资源耗尽问题。当线程池中线程数量达到corePoolSize后，再有新任务进来，则会将任务放入该队列的队尾，等待被调度。如果队列已经是满的，则创建一个新线程，如果线程数量已经达到maxPoolSize，则会执行拒绝策略。

②LinkedBlockingQuene

基于链表的无界阻塞队列（其实最大容量为Interger.MAX），按照FIFO排序。由于该队列的近似无界性，当线程池中线程数量达到corePoolSize后，再有新任务进来，会一直存入该队列，而基本不会去创建新线程直到maxPoolSize（很难达到Interger.MAX这个数），因此使用该工作队列时，参数maxPoolSize其实是不起作用的。

③SynchronousQuene

一个不缓存任务的阻塞队列，生产者放入一个任务必须等到消费者取出这个任务。也就是说新任务进来时，不会缓存，而是直接被调度执行该任务，如果没有可用线程，则创建新线程，如果线程数量达到maxPoolSize，则执行拒绝策略。

④PriorityBlockingQueue

具有优先级的无界阻塞队列，优先级通过参数Comparator实现。

六、threadFactory 线程工厂

创建一个新线程时使用的工厂，可以用来设定线程名、是否为daemon线程等等【注1Daemon 线程】

七、handler 拒绝策略

当工作队列中的任务已到达最大限制，并且线程池中的线程数量也达到最大限制，这时如果有新任务提交进来，该如何处理呢。这里的拒绝策略，就是解决这个问题的，jdk中提供了4中拒绝策略：

①CallerRunsPolicy

该策略下，在调用者线程中直接执行被拒绝任务的run方法，除非线程池已经shutdown，则直接抛弃任务。

②AbortPolicy

该策略下，直接丢弃任务，并抛出RejectedExecutionException异常。

③DiscardPolicy

该策略下，直接丢弃任务，什么都不做。
④DiscardOldestPolicy

该策略下，抛弃进入队列最早的那个任务，然后尝试把这次拒绝的任务放入队列

B+Tree详解

Tue, 04 Jul 2023 00:05:38 +0000

B+Tree的来源

在日常的开发和面试中经常接触的就是InnoDB存储引擎中的B+Tree索引。而学习B+Tree之前先要学习二叉查找树，平衡二叉树，B数这三种数据结构。

二叉查找树

上图就是根据User表创建的二叉查找树的索引。通过图片可知二叉查找树中的每个节点都存储了键(key)和值(data)。key对应的就是表中的id，data对应就是表中的一行数据。

二叉查找树的特点就是任意节点的左子节点的key都小于当前节点的key，右节点的key都大于当前节点key。

应用场景：假定需要查询id为17的用户信息，使用二叉查找树的查询流程是：

1.首先找到根节点，把需要查询的id和当前节点进行比较，发现17大于当前节点的key(10)。根据二叉查找树的特点接下来需要把根节点的右子节点作为当前节点。

2.继续使用17和当前节点的key(13)进行比较。原理和步骤1同理。

3.继续使用17和当前节点的key(17)进行比较，发现满足查询条件。那么就用当前节点中取出data(id=17,name=dy)

通过分析查找流程可知查询id=17的数据(data)一共进行了三次匹配就可以完成。如果不使用二叉查找树那么对表逐个比较那么就需要7次才能匹配到。

平衡二叉树

上述已经学习了二叉查找树这种数据结构，但是在极端的情况下二叉查找树会退化成单向链表。

如果数据比较极端，生成了上面的这种二叉查找树，那么刚才的id=17的查询会发现在二叉查找树的结构中依然需要查找7次。那么这样就和全表扫描没有任何区别。并不一定说极端情况就是退化成单向链表，只要二叉查找树的高度过高并且不平衡的情况下效率就是很低。所以这种结构就存在很大的缺陷，为了解决这个问题就引出平衡二叉树。平衡二叉树的特点就是满足二叉查找树的基础上，添加一个新的要求。每个节点的左右子树的高度差距不能超过1。

PS：如果对数据进行添加，修改和删除操作导致平衡二叉树不平衡时，那么平衡二叉树就根据树上节点的数据进行保持平衡。

PS：平衡二叉树相对于二叉查找树来说，效率更加稳定。

B树

由于数据的核心就是不丢失，所以数据库中的数据一般都是存储在磁盘上。但是存储磁盘最大的问题就是速度很慢，相比较内存来说最小差距也在百倍左右，在极端情况下可能差距上万倍。而性能的差距主要原因就是频繁的IO操作。那么如果当表中的数据量比较大的时候那么平衡二叉树就会出现n层的情况(平衡二叉树和二叉查找树有共同的特点，就是节点上存储数据)。

通过上图可知在数据量比较大的情况下平衡二叉树也存在很大的性能问题。造成这样问题的核心原因就是单个节点存在单个key和data。那么为了解决平衡二叉树存在的这个问题就需要从单节点存储的数据入手。
创建一种单节点可以存储多个key和data的平衡树。这就是B树。

PS：存储单元称之为页(页其实就是磁盘的每个磁盘块)

通过上述图片可以得知一个结果，就是B树相较于平衡二叉树来说最大的改变就是每个节点可以存储更多的key和data。并且每个节点(页)可以拥有更多的子节点，这样的设计就造成了树的高度降低了。由于树的高度降低了那么在查找数据的时候读取磁盘的次数就减少了(降低IO操作)。那么效率也就提升了。

应用场景： id=29的数据。

1.首先找到页1.判断29是页1中的17和35的区间。那么就根据页1中P2的指针找到页3.

2.将29和页3中的数据进行比较。26和30发现29依然存在于这个区间，那么继续使用页3中的p2的指针找到页8.

3.将29和页8的数据进行比较，可以得到匹配的key(29)从而读取对用的data。

B+Tree

B+树就是B树的一个升级。首先咱们看B+树的结构。

首先分析B+树和B树的区别：

1.B+树上除叶子节点其他节点是不存储数据的。B树上每个节点都存储了key和data。而B+树只在叶子节点上存储数据，其他节点只存储key。

为什么要进行这样的改变呢？

以innoDB存储引擎来说，数据库中页的大小是固定的，每页的默认大小为16K。如果页不存储数据(data)就可以存储更多的key,那么就可以尽可能的减少树的高度。总结来说B+树相对于B树来说又矮又胖。这时候如果查询那么就会降低很多IO操作。

假定一个页16K可以存储1000个key。那么3层的B+树就可以存储100010001000=10亿条数据。而且根节点是常驻内存的，也就是说查询10亿条数据只需要进行2次IO操作。

2.B+树所有的数据都存储在叶子节点上并且是按照顺序排列的。那么使用B+树完成范围查找，排序查找，分组查找，去重查找就会很简单，效率也比较高。而B树就不可以。因为B树的数据是分散个各个节点上的。

3.B+树上每页之间是一个双向链表进行链接，叶子节点中的数据都是使用单向链表链接的。但是需要记得一点的是B树也可以加链表。

PS：InnoDB存储引擎中索引就是这样存储的。InnoDB中的聚集索引就是上面的结构。需要记住一点是MyISAM中依然使用的是B+树，结构是一样的，原理也是一样的，区别在于存储不是数据而是数据的文件地址。

聚集索引和非聚集索引

聚集索引(聚簇索引):如果数据库使用InnoDB存储引擎，那么表中的数据一定会有一个主键，如果用户不创建主键系统也会帮你创建一个隐式的主键。

之所以一定要有主键因为InnoDB把数据放在B+树上，而B+树上的key就是主键。如果以主键构建的B+树索引那么就称之为聚集索引。

非聚集索引：以主键以外的列作为key构建B+树索引就称之为非聚集索引

使用聚集索引查找

select * from user where id>=18 and id<40

核心思想：
根节点是常驻内存的，所有不需要进行IO操作
根据各节点找到对应的p，根据p的指针找到对应的下一级页。最终达到叶子节点。通过二分查找法定位到数据位置，通过单向链表或者当前页的数据，再通过双向链表获取下一页的数据，最终获取所有需要查询的数据。

使用非聚集索引查找

Java - SPI机制

Mon, 03 Jul 2023 21:34:39 +0000

1. 概念

在面向对象的设计原则中，一般推荐模块之间基于接口编程，通常情况下调用方模块是不会感知到被调用方模块的内部具体实现。一旦代码里面涉及具体实现类，就违反了开闭原则。如果需要替换一种实现，就需要修改代码。

为了实现在模块装配的时候不用在程序里面动态指明，这就需要一种服务发现机制。Java SPI 就是提供了这样一个机制：为某个接口寻找服务实现的机制。这有点类似 IOC 的思想，将装配的控制权移交到了程序之外。

SPI 英文为 Service Provider Interface 字面意思就是：“服务提供者的接口”，我的理解是：专门提供给服务提供者或者扩展框架功能的开发者去使用的一个接口。

SPI 将服务接口和具体的服务实现分离开来，将服务调用方和服务实现者解耦，能够提升程序的扩展性、可维护性。修改或者替换服务实现并不需要修改调用方。

Java SPI（Service Provider Interface）是Java官方提供的一种服务发现机制，它允许在运行时动态地加载实现特定接口的类，而不需要在代码中显式地指定该类，从而实现解耦和灵活性。

Java spi 最大优点：热插拔

实现类方法通过pom依赖服务接口感知。服务启动时通过依赖查找对应META-INF目录下是否有文件指定方法全路径，有的话初始化。 ****通过切断依赖控制实现方法的初始化.

2. 实现原理

Java SPI 的实现原理基于 Java 类加载机制和反射机制。

nvm安装

Sat, 01 Jul 2023 12:35:55 +0000

1、nvm安装

1、双击安装文件 nvm-setup.exe

2、选择nvm安装路径

3、选择nodejs路径

4、确认安装即可

5、安装完确认

打开CMD，输入命令 nvm ，安装成功则如下显示。可以看到里面列出了各种命令，本节最后会列出这些命令的中文示意。

6、nvm管理node版本

1、查看所有可安装的版本

nvm list available

2、查看本地已经安装的所有版本

nvm list

3、安装，命令中的版本号

nvm install 14.18.1

4、使用指定node版本

nvm use 14.18.1

5、卸载

nvm uninstall 14.18.1

7、其他nvm相关命令

nvm arch ：显示node是运行在32位还是64位。

nvm install [arch] ：安装node， version是特定版本也可以是最新稳定版本latest。可选参数arch指定安装32位还是64位版本，默认是系统位数。可以添加–insecure绕过远程服务器的SSL。

nvm list [available] ：显示已安装的列表。可选参数available，显示可安装的所有版本。list可简化为ls。

nvm on ：开启node.js版本管理。

nvm off ：关闭node.js版本管理。

nvm proxy [url] ：设置下载代理。不加可选参数url，显示当前代理。将url设置为none则移除代理。

nvm node_mirror [url] ：设置node镜像。默认是https://nodejs.org/dist/。如果不写url，则使用默认url。设置后可至安装目录settings.txt文件查看，也可直接在该文件操作。

nvm npm_mirror [url] ：设置npm镜像。https://github.com/npm/cli/archive/。如果不写url，则使用默认url。设置后可至安装目录settings.txt文件查看，也可直接在该文件操作。

nvm uninstall ：卸载指定版本node。

nvm use [version] [arch] ：使用制定版本node。可指定32/64位。

nvm root [path] ：设置存储不同版本node的目录。如果未设置，默认使用当前目录。

常用类似 maven idea 的命

Tue, 27 Jun 2023 09:52:52 +0000

生成.ipr文件:

mvn idea:project

生成.iws文件:

mvn idea:workspace

生成.iml文件:

mvn idea:module

:::info .iml 文件是 IntelliJ IDEA 的项目文件，它包含了项目的配置信息，比如模块、依赖项、编译选项等等。每个 IntelliJ IDEA 项目都有一个 .iml 文件，它用来描述项目的结构和配置。

在 IntelliJ IDEA 中，一个项目通常由多个模块组成，每个模块都有一个 .iml 文件。.iml 文件中包含了模块的名称、源代码目录、编译选项、依赖项等信息，IntelliJ IDEA 会根据这些信息来构建和运行项目。

当您在 IntelliJ IDEA 中创建一个新项目或者新模块时，IDEA 会自动为您生成一个 .iml 文件。如果您手动删除了 .iml 文件，IntelliJ IDEA 会重新生成它。.iml 文件通常不需要手动编辑，除非您需要手动修改项目的配置信息。

:::

生成.idea文件:

 mvn -U idea:idea

Anaconda创建、删除虚拟环境以及一些conda常用指令

Wed, 14 Jun 2023 11:48:02 +0000

一、Anaconda创建、删除和复制环境

1. 创建虚拟环境

 conda create -n your_env_name python=x.x
# 在创建环境的同时安装必要的包
conda create -n your_env_name numpy matplotlib python=x.x
# 在指定的虚拟环境中安装额外的包
conda install -n your_env_name package_name
#例子
conda create -n name python=3.9
#创建一个环境并且在创建时自动安装yml文件中的库
conda env create -n name -f environment.yml

查看已经安装的环境(以下两条输出相同)

conda-env list

base                  *  D:\tools\anaconda3
evn_dqs                  D:\tools\anaconda3\envs\evn_dqs
py3716                   D:\tools\anaconda3\envs\py3716


conda info --envs

2. 激活虚拟环境

conda activate py3716
conda activate evn_dqs
conda activate base

# 退出当前环境
deactivate py3716

3. 删除虚拟环境

conda remove -n py3716 --all
# 删除虚拟环境中的某个包：
conda remove --name your_env_name package_name

二、conda常用指令

深度分页问题分析和优化

Mon, 15 May 2023 09:53:48 +0000

b站up主极海Channel（UID1525355）发动态暗示b站没有做深度优化

深度分页存在性能风险，产品约束了前端，后端没限制住

涉及深度分页查询

找了下对应的解决方案

深度分页问题

后端开发为了防止一次加载太多数据到内存，对内存占用和IO读取开销太大，一般使用limit 关键字进行分页加载数据（懒加载，再需要查看时再加载数据），查询employess表中第[N,N+m]条记录，先看下测试数据集大小：

分别查询[10000,10003]三条记录和[100000,100003]三条记录，并观察执行时间。

mysql> select * from employees limit 10000,3；

发现在查询结果集数量一定的情况下，查询时间和查询深度成正比。

深度分页效率低原因： limit m，n查询过程是先回表查询m+n条记录，然后丢掉前m条，取后面n条结果返回。

深度分页优化

(1) 通过子查询优化

说明:在employees表中，emp_no是主键，也即聚集索引，在birth_date列创建一个普通非聚集索引。

mysql> create index birth_date_index on 
employees(birth_date);--在birth_date字段创建非聚集索引

查询语句1：

mysql> select * from employees 
where birth_date > '1955-01-01' 
order by emp_no 
limit 100000,3;

查询过程：

查询语句2：

mysql> select *  from employees
 where emp_no >=
 	 (select emp_no from employees
 	  where birth_date > '1955-01-01' 
 	  order by emp_no limit 100000,1) 
 	  limit 3;

前端el-date-picker标签异常排查小记

Tue, 09 May 2023 19:19:38 +0000

<el-col layout-size="medium">
<el-form-item
  label="使用起止日期"
  prop="daterangeBeginAndEndTime"
>
  <el-date-picker
    v-model="dataAppyDetlLedFormEdit.daterangeBeginAndEndTime"
    :picker-options="pickerOptionsEidte"
    type="daterange"
    start-placeholder="开始日期"
    end-placeholder="结束日期"
    value-format="timestamp"
    :clearable="false"
    @blur="
      changePackageTime(
        dataAppyDetlLedFormEdit.daterangeBeginAndEndTime
      )
    "
  >
  </el-date-picker>
</el-form-item>
</el-col>

上述前端标签在update更新的时候使用起止日期显示内容一直为空，通常使用this.$forceUpdate()强制更新视图模型可以解决数据显示问题

看网上解释是说：数据层次太多导致render函数没有自动更新，需要调用this.$forceUpdate()强制刷新，触发updated生命周期。

this.$forceUpdate()的作用：迫使VUE实例重新渲染。注意此方法只影响实例本身和插入插槽内容的子组件，并非所有的子组件。

若使用本文方法还未解决，建议参考 vue双向绑定失效，视图不更新，$set()失效解决办法，使用时间戳加强制更新的方式解决此类问题。

但该处不是此原因。

    showEditDialog(row) {
      this.dataAppyDetlLedFormEdit = Object.assign({}, row)
      this.operateType = 'update'
      this.dataAppyDetlLedFormEdit.daterangeBeginAndEndTime = new Array(2)

      this.dataAppyDetlLedFormEdit.daterangeBeginAndEndTime[0] = this.dataAppyDetlLedFormEdit.begntime
      this.dataAppyDetlLedFormEdit.daterangeBeginAndEndTime[1] = this.dataAppyDetlLedFormEdit.endtime
      this.editDialogVisible = true
      this.dataAppyDetlLedFormNoBegntimeEndtimeUpdate = true
      this.dataAppyDetlLedFormBegntimeEndtimeAdd = false

      this.$forceUpdate()
      console.log(
        'daterangeBeginAndEndTime' +
          this.dataAppyDetlLedFormEdit.daterangeBeginAndEndTime
      )
      console.log('begntime' + this.dataAppyDetlLedFormEdit.begntime)
      console.log('endtime' + this.dataAppyDetlLedFormEdit.endtime)
    },
    changePackageTime(daterangeBeginAndEndTime) {
      this.dataAppyDetlLedFormEdit.begntime = daterangeBeginAndEndTime[0]
      this.dataAppyDetlLedFormEdit.endtime = daterangeBeginAndEndTime[1]
      this.$forceUpdate()
    },

通过console.log观察测试环境为时间戳

daterangeBeginAndEndTime1683625453000,1691401453000

而生产环境为

daterangeBeginAndEndTime Thu Jan 0108:00:00 CST 1970,Thu Jan 0108:00:00 CST 1970

redis模糊批量删除

Fri, 05 May 2023 17:07:30 +0000

没有直接批量模糊删除的办法，只有模糊获取对应集合，批量删除

	private static StringRedisTemplate stringRedisTemplateS;
	
	public static final String PREFIX = "dqs:";
    public static final String PREFIX_API = "api:";
	
	/**
     * 模糊匹配key 并删除
     * @param key
     */
    public static void deletLikeKeyStr(String key) {
        Set<String> keys = stringRedisTemplateS.keys(PREFIX+ key+ "*");
        stringRedisTemplateS.delete(keys);
    }

npm常用命令

Sun, 23 Apr 2023 11:20:10 +0000

npm config set prefix "D:\tools\nvm\node_global"
npm config set cache "D:\tools\nvm\node_cache"

npm list --depth 0

+-- babel-core@6.26.3
+-- babel-preset-env@1.7.0
+-- no@0.0.1
+-- nrm@1.2.5
`-- optional@0.1.4

查看npm设置

npm config list --l 或 npm config ls -l #查看全部配置项
npm config list #查看简略配置信息
npm config get <key>  #查看某一项的配置信息
npm config set <key> <value> #设置某一项的配置信息

npm 查看和修改 prefix和 cache配置

我一般选择用命令的方式设置，并且将这两个文件夹配置在其他盘符防止权限问题

# 设置全局包目录
npm config set cache "D:\tools\nvm\node_cache"
#设置缓存目录
npm config set prefix "D:\tools\nvm\node_global"

.npmrc文件

在该文件中可以查看或手动修改配置信息。
用 npm config list查看所在路径，里面带有.npmrc的那个就是径了。

JVM参数说明

Tue, 18 Apr 2023 14:17:43 +0000

-Xms30720m -Xmx30720m -XX:MaxDirectMemorySize=1024m -XX:+PrintGC -XX:+PrintGCDateStamps -Xloggc:/home/admin/edas_logs/logs -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/edas_logs/logs -XX:+UseG1GC -XX:PermSize=512m -XX:MaxPermSize=512m -Xmn5G -XX:SurvivorRatio=8 -XX:-UseAdaptiveSizePolicy  -Dspring.cloud.alicloud.acm.group=hsa-mbs-local-prd -Dspring.application.name=hsa-mbs-local      


-XX:+UseG1GC -XX:PermSize=512m -XX:MaxPermSize=512m -Xmn5G -XX:SurvivorRatio=8 -XX:-UseAdaptiveSizePolicy  -Dspring.cloud.alicloud.acm.group=hsa-mbs-local-prd -Dspring.application.name=hsa-mbs-local

JAVA_HOME="/home/admin/jdk1.8.0_261"
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -Xms4096m -Xmx4096m -Xmn2g - XX:PermSize=512m -XX:MaxPermSize=512m -XX:+DisableExplicitGC - XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly"

JAVA_HOME="/home/admin/jdk1.8.0_261"
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -Xmsm8192m -Xmx8192m -Xmn4g -XX:PermSize=1024m -XX:MaxPermSize=1024m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly"

参数说明

1.JVM(Java Virtual Machine)

1.-Xms 初始堆大小

2.-Xmx 最大堆大小

3.-Xmn 青年代大小

4.-Xss 每个线程的堆栈大小

Spring boot自定义注解实现接口缓存

Mon, 17 Apr 2023 14:29:05 +0000

结合spring boot aop切片编程的特性，采取自定义注解的形式，借助缓存redis实现接口缓存，提高稳定接口访问效率

自定义注解

/**
 * 接口缓存自定义注解
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ApiCache {
    // 缓存时间，默认缓存一分钟
    long validityPeriod() default 60;
}

定义切入点

package cn.hsa.neu.dqs.common.aop;


import cn.hsa.hsaf.core.framework.util.DateUtil;
import cn.hsa.neu.dqs.common.utils.CacheUtil;
import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.JSONObject;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.Signature;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.reflect.MethodSignature;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.ResponseBody;

import java.lang.reflect.Method;
import java.util.Arrays;

@Slf4j
@Aspect
@Component
public class ApiCacheAspect {

	@Autowired
	CacheUtil cacheUtil;


	@Around("@annotation(cn.hsa.neu.dqs.common.aop.ApiCache)")
	public Object action(ProceedingJoinPoint joinPoint) throws Throwable {

		String bizDate = DateUtil.getCurrentDate_String(DateUtil.DATEFORMAT);

		Signature signature = joinPoint.getSignature();

		// 反射获取目标类名
		String className = joinPoint.getTarget().getClass().getName();
		// 获取目标方法的名称
		String methodName = signature.getName();
		// 获取方法传入参数
		String params = Arrays.toString(joinPoint.getArgs());
		// 合成键值
		String key = className+":"+methodName+":"+bizDate+":"+params;
		// 被切的方法 返回类型
		Class<?> methodReturnType = Object.class;
		if (signature instanceof MethodSignature) {
			MethodSignature methodSignature = (MethodSignature) signature;
			// 被切的方法
			Method method = methodSignature.getMethod();
			// 返回类型
			methodReturnType = method.getReturnType();
		}

		// 获取注解的方法
		Method method = ((MethodSignature) joinPoint.getSignature()).getMethod();
		ApiCache annotation = method.getAnnotation(ApiCache.class);
		// 获取缓存有效期
		 long validityPeriod = annotation.validityPeriod();
		// 获取缓存的接口返回值
		Object response = CacheUtil.getStr(key);
		if(response == null){
			// 如果没有缓存接口返回值则执行原方法
			log.info(key+":cache get!");
			response = joinPoint.proceed();
			// 保存缓存
			CacheUtil.putStrWithTimeout(key, JSON.toJSONString(response),validityPeriod);
		}else{
			// 否则直接从缓存中获取接口返回值
			response=JSONObject.parseObject(response.toString(), methodReturnType);
		}
		return response;
	}
}

示例

使用时直接在需要配置接口缓存的接口controller/service上加上刚才定义的自定义注解即可。（可通过参数validityPeriod配置缓存有效时间）

多线程场景下使用 ArrayList

Sat, 15 Apr 2023 15:04:46 +0000

ArrayList应该是我们比较常用的集合了,在一般场景下使用是没有问题的，

但是如果在多线程场景下，应该怎么使用呢？

主要有两种方式，如下：

方式一：使用Collections.synchronizedList()

ArrayList 不是线程安全的，如果遇到多线程场景，

可以通过 Collections 的 synchronizedList 方法将其转换成线程安全的容器后再使用。

案例：

public void testSynchronizedArrayList(){
	ArrayList<String> arrayList = new ArrayList<String>();
	arrayList.add("a");
	List<String> synchronizedList = Collections.synchronizedList(arrayList);
	synchronizedList.add("a");
}

//Collections.synchronizedList源码
public static <T> List<T> synchronizedList(List<T> list) {
	//判断数组是否实现了RandomAccess,如果是选择创建SynchronizedRandomAccessList对象
	//否则则创建SynchronizedList对象
	return (list instanceof RandomAccess ?
					new SynchronizedRandomAccessList<>(list) :
					new SynchronizedList<>(list));
}
//SynchronizedRandomAccessList源码
SynchronizedRandomAccessList(List<E> list) {
	super(list);
}
// SynchronizedList源码
SynchronizedList(List<E> list) {
	super(list);
	this.list = list;
}
// SynchronizedCollection源码
final Object mutex;     
// Object on which to synchronize
SynchronizedCollection(Collection<E> c) {
	this.c = Objects.requireNonNull(c);
	mutex = this;
}
// 然后其对应的add方法
final Object mutex;   //对mutex对象进行加锁，而不是对整个方法进行加锁，锁的粒度下降，效率提高
final Collection<E> c;

public boolean add(E e) {
	synchronized (mutex) {return c.add(e);}
}

方式二：使用CopyOnWriteArrayList

copyOnWriteArrayList相当于每次使用都会复制一份新的ArrayList
保证隔离，这样子线程使用就安全了，但是有个缺点，就是比较费内存，而且如果是增删改场景较多的时候，数组复制会浪费较多的时间

CompletableFuture.allOf(XXX).join();

Sat, 15 Apr 2023 14:05:37 +0000

public class Demo5 {
    public static void main(String[] args) {
        long time = System.currentTimeMillis();

        Map<String,Object> map = new ConcurrentHashMap<>();
        CompletableFuture.allOf(
                CompletableFuture.runAsync(() -> {
                    ThreadTool.printTimeAndThread("业务1开始执行了");
                    ThreadTool.sleepMillis(200);
                    map.put("1","执行完成");
                }),
                CompletableFuture.runAsync(() -> {
                    ThreadTool.printTimeAndThread("业务2开始执行了");
                    ThreadTool.sleepMillis(200);
                    map.put("2","执行完成");
                }),
                CompletableFuture.runAsync(() -> {
                    ThreadTool.printTimeAndThread("业务3开始执行了");
                    ThreadTool.sleepMillis(200);
                    map.put("3","执行完成");
                })
        ).join();

        long ms = System.currentTimeMillis() - time;
        System.out.println("办法总消耗时:" + ms + " ms");
        System.out.println(map.toString());

    }
}

    @Override
    public List<Map<String, Object>> analysisSum(String bizDate) {
        List<Map<String, Object>> all= new CopyOnWriteArrayList<>();
        CompletableFuture.allOf(
                CompletableFuture.supplyAsync(() -> 
											  dirtyDataGroupDAO.queryDirtyDataAnalysisSumA(bizDate), 
											  commonThreadPool).thenApply(data -> all.addAll(data)),
                CompletableFuture.supplyAsync(() -> dirtyDataGroupDAO.queryDirtyDataAnalysisSumB(bizDate),
											  commonThreadPool).thenApply(data -> all.addAll(data)),
                CompletableFuture.supplyAsync(() -> dirtyDataGroupDAO.queryDirtyDataAnalysisSumC(bizDate),
											  commonThreadPool).thenApply(data -> all.addAll(data)),
                CompletableFuture.supplyAsync(() ->{map
                    Map<String, Object> map=new HashMap<>();
                    map.put("id","1");
                    map.put("label","现存脏数据总量");
                    map.put("pic","./assets/zlsjl.svg");
                    map.put("num",num);
                    map.put("unit","");
                    return map;
                },commonThreadPool).
                        thenApply(data -> all.add(data))
        ).join();
        return all;
    }

List<CompletableFuture> futureAll = allSumEvtCdOs.stream().map(cdoList ->
 CompletableFuture.supplyAsync(() -> 
		 monSetlTcsNoclrSetldService.deleteNoclrSetlAndFund(cdoList.stream().map(data -> {
	 String strValue = data.getFixmedinsCode() + "-" + data.getFeeClrId() + "-" + data.getEvtsn();
	 boolean locking = AsyncLockTcsUtil.
		 islocking(TcsCacheConst.ASYNC_LOCK_ASYNC_INSERTLIQUIDATIONINFO_PRODUCER + timeStrKey, strValue);
	 if (locking) {
		 throw new RuntimeException("locking");
	 }
	 AsyncLockTcsUtil.lockMin(TcsCacheConst.ASYNC_LOCK_ASYNC_INSERTLIQUIDATIONINFO_PRODUCER + timeStrKey, strValue);
	 LiquNedUIDTO lieuNeedDTO = new LiquNedUIDTO();
	 lieuNeedDTO.setSemaphore(semaphore);
	 BeanUtils.copyProperties(data, lieuNeedDTO, LiquNedUIDTO.class);
	 return lieuNeedDTO;
 }).collect(Collectors.toList()), timeStrKey), commonThreadPool)).collect(Collectors.toList());
CompletableFuture.allOf(futureAll.toArray(new CompletableFuture[0])).join();

@PostMapping("/executeMethod")
  private String executeMethod(){
    String bizDate = DateUtil.getCurrentDate_String("yyyy-MM-dd");
    List<String> synchronizedList = Collections.synchronizedList(new ArrayList<>());
    List<Map<String, Object>> mapList = dirtyDataGroupService.analysisSort(bizDate);
    mapList.forEach(data->synchronizedList.add(String.valueOf(data.get("SUBSYS_CODG"))));
    List<CompletableFuture> futureAll = synchronizedList.stream().map(subsysCodg ->
    CompletableFuture.supplyAsync(() -> dirtyDataGroupService.analysisBar(bizDate, subsysCodg)
    , commonThreadPool)).collect(Collectors.toList());
    CompletableFuture.allOf(futureAll.toArray(new CompletableFuture[0])).join();
    return "SUCCESS";
  }

vue: 2.6.10 随笔

Thu, 02 Mar 2023 10:33:54 +0000

Vue的el-form 提供了表单校验功能，:rules 属性设置校验规则，并通过 el-form-item 的 prop 属性绑定校验规则。组件封装，让前端校验更方便

Thread-CompletableFuture-Test

Sat, 16 Jul 2022 18:23:10 +0000

Thread

public class CompletableFutureDemo {
  long st = System.currentTimeMillis();

  /**
* 全流式处理转换成CompletableFuture[]+allOf组装成一个无返回值CompletableFuture，join等待执行完毕。返回结果whenComplete获取
*/
  @Test
  public void CompletableFutureTest() {
    // 结果集
    List<String> result = new ArrayList<>();
    // 需要处理的数据集 10个线程，每个线程处理一个str
    List<String> lists = Arrays.asList("a", "b", "c", "d", "e", "f", "g", "h", "i", "j");
    //定长10线程池
    ExecutorService exs = Executors.newFixedThreadPool(10);
    CompletableFuture[] cfs = lists.stream().map(str -> CompletableFuture.supplyAsync(() -> calc(str), exs)
                         //thenAccept只接受不返回不影响结果
                         .thenApply("final-"::concat)
                         //获取任务完成先后顺序
                         .whenComplete((v, e) -> {
                          System.out.println("任务" + v + "完成!result=" + v + "，异常 e=" + e + "," + new Date());
                                                   result.add(v);
                                                 })).toArray(CompletableFuture[]::new);
    //等待总任务完成，但是封装后无返回值，必须自己whenComplete()获取
    CompletableFuture.allOf(cfs).join();
    System.out.println("任务完成先后顺序，结果list2=" + result + ",耗时=" + (System.currentTimeMillis() - st));
    exs.shutdown();
    Assert.assertTrue(CollUtil.isNotEmpty(result));
  }

  /**
* 循环创建CompletableFuture list,组装返回一个有返回值的CompletableFuture，返回结果get()获取
*/
  @Test
  public void CompletableFutureTest2() {
    // 结果集
    List<String> result;
    // 需要处理的数据集 10个线程，每个线程处理一个str
    List<String> lists = Arrays.asList("a", "b", "c", "d", "e", "f", "g", "h", "i", "j");
    //定长10线程池
    ExecutorService exs = Executors.newFixedThreadPool(10);
    List<CompletableFuture<String>> futureList = new ArrayList<>();
    try {
      for (String str : lists) {
        //异步执行
        CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> calc(str), exs)
          //thenAccept只接受不返回不影响结果
          .thenApply("final-"::concat)
          //如需获取任务完成先后顺序，此处代码即可
          .whenComplete((v, e) ->
                        System.out.println("任务" + v + "完成!result=" + v + "，异常 e=" + e + "," + new Date()));
        futureList.add(future);
      }
      //1.构造一个空CompletableFuture，子任务数为入参任务list size
      CompletableFuture<Void> allDoneFuture = CompletableFuture
        .allOf(futureList.toArray(new CompletableFuture[futureList.size()]));
      //2.流式（总任务完成后，每个子任务join取结果，后转换为list）
      result = allDoneFuture.thenApply(v -> futureList.stream().map(CompletableFuture::join)
                                       .collect(Collectors.toList())).get();
      System.out.println("任务完成先后顺序，结果list2=" + result + ",耗时=" + (System.currentTimeMillis() - st));
      Assert.assertTrue(CollUtil.isNotEmpty(result));
    } catch (InterruptedException | ExecutionException e) {
      e.printStackTrace();
    } finally {
      exs.shutdown();
    }

  }

  private String calc(String str) {
    try {
      if (str.equals("a")) {
        Thread.sleep(3000);
      } else if (str.equals("b")) {
        Thread.sleep(5000);
      } else {
        Thread.sleep(1000);
      }
      str = str.concat("_").concat(Thread.currentThread().getName());
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
    return str;
  }
}

Find

Mon, 01 Jan 0001 00:00:00 +0000

Accelerate Blog

关于我

你好，我是 Acclerate。

写代码的日子

走路的日子

南昌

杭州

海南

烟台

关于这个博客

使用CloudFlare部署GitHub仓库里的静态项目

怎么在 Windows 下查所有运行任务和端口

一、查看所有运行中的任务

二、查看所有端口与对应进程

三、根据端口反查进程

四、根据 PID 查任务详情

更直接的办法

五、结束指定任务

Nginx 配置

SSL证书

直接返回内容

Nginx动静分离配置

Lock4j + Redis基于 Redis 的 AP 特性来实现分布式锁

**@Lock4j**** 方法级分布式锁注解**

1. 整体作用

2. 注解元信息

3. 属性逐条解析

3.1 **name**：锁资源名称（前缀）

3.2 **executor**：锁执行器类型

3.3 **keys**：动态 key 部分（SpEL）

微服务模块化结构规范（Spring Cloud + Gradle）

微服务模块化结构规范（Spring Cloud + Gradle）

一、模块划分与职责

二、模块依赖关系

时间戳防重放机制深度解析

由浅入深地为您剖析“时间戳防重放”机制，结合您提供的 PayRsaSignService 代码进行深度解析。

一、 本质：给请求贴一张“过期日期”

二、 形成原因：为什么光有签名还不够？

三、 现象：如果不防重放会发生什么？

四、 核心处理办法（结合代码深度讲解）

1. 取时间：客户端与服务端对表

2. 算差值：容忍网络延迟

挂载自定义 JAR 导致 Pod 漂移到其他 Node 的深层次原因分析

shenyu挂载自定义 JAR 导致 Pod 漂移到其他 Node 的深层次原因分析

文档结构

一、核心概念纠偏：Pod 为什么会"漂移"？

sign-plugin-验证手册

ShenYu 加签验签验证手册（SignPlugin × RequestPlugin × DividePlugin）

一、需求背景与协议总览

1.1 什么时候需要加签与验签

1.2 协议要素（本仓库 shenyu-client-core 的 sign 包已实现）

1.3 待签名串格式

ShenYu 网关注册接入 — 改动总结

✅ ShenYu 网关注册接入 — 改动总结

一、核心目标

二、关键决策（踩坑后定稿）

三、改动文件清单（本次新增/修改，共 7 处）

依赖层（2 处）

代码层（4 处，4 个 Controller 加注解）

MapStruct 语法和技术点说明及最小用例

一、 MapStruct 语法和技术点说明及最小用例

1. @Mapper 注解与 componentModel

2. 多源参数映射

divide-plugin-验证手册

ShenYu 2.6.1 divide 插件功能验证手册

环境

Apache ShenYu Divide 插件深度解析

一、入门层：核心定位与架构位置

1. 插件定位

2. 在插件链中的位置

3. 核心价值

maven&gradle

一、bootRun 是不是推荐方式?

bootRun 本质

三种开发期运行方式对比(你的项目场景)

bootRun 的优缺点

win查看所有端口和PID

Spring使用@Transactional 管理事务，Java事务详解。

Java线上排查问题工具——Arthas

Spring事务源码解析

`@Lock4j` 方法级分布式锁注解

3.1 `name`：锁资源名称（前缀）

3.2 `executor`：锁执行器类型

3.3 `keys`：动态 key 部分（SpEL）

由浅入深地为您剖析“时间戳防重放”机制，结合您提供的 `PayRsaSignService` 代码进行深度解析。

一、本质：给请求贴一张“过期日期”

二、形成原因：为什么光有签名还不够？

三、现象：如果不防重放会发生什么？

四、核心处理办法（结合代码深度讲解）

1.2 协议要素（本仓库 `shenyu-client-core` 的 `sign` 包已实现）

1. `@Mapper` 注解与 `componentModel`