发表更新 太阳当空赵先生 工具分享14 分钟读完 (大约2088个字)

OpenClaw 自动化配置完全指南：从零搭建高效 AI 工作流

前言

OpenClaw 是一个强大的 AI 助手框架，但要发挥最大效能，需要一套可靠的自动化配置。本文将手把手教你如何配置 OpenClaw 的核心自动化功能，包括：

  • 定时模型检查（避免模型失效导致意外）
  • 自动化任务推送（到飞书/Telegram/Discord）
  • 模型配置健康监控脚本
  • 常见问题与解决方案

一、OpenClaw 模型配置详解

OpenClaw 的模型配置文件位于 ~/.openclaw/config.yaml，这是你选择 AI 模型的核心配置。

1.1 基础配置结构

1
2
3
4
5
6
7
8
9
10
default_model: openrouter/auto
models:
  # 主要模型（按优先级排序）
  - openrouter/auto              # 自动路由，智能选择可用模型
  - openrouter/hunter-alpha      # 1M context，最强推理
  - openrouter/healer-alpha      # Vision + Tools + Reasoning
  - arcee-ai/trinity-large-preview:free  # 131K, 创意写作强
  - nvidia/nemotron-3-super-120b-a12b:free # 262K, 工具调用
  - stepfun/step-3.5-flash:free  # 256K, #1 最受欢迎
  - xiaomi/mimo-v2-flash:free    # 小米模型（需验证可用性）

1.2 模型选择策略

  • openrouter/auto：自动路由，优先使用可用免费模型中最高性能的
  • hunter-alpha：适合复杂推理、长文档分析（1M context）
  • healer-alpha：支持视觉理解，适合图片+文本混合任务
  • step-3.5-flash：StepFun 旗舰，综合性能最强，免费且稳定

配置建议：

  • 至少包含 openrouter/auto 作为 fallback
  • 保留 3-5 个高性能模型，OpenClaw 会自动负载均衡
  • 定期检查模型可用性（见下文脚本）

二、定时任务配置（Crontab）

OpenClaw 支持通过系统 crontab 定时执行任务并推送通知。但需要注意环境变量问题。

2.1 常见坑：cron 找不到 node

如果你直接用 openclaw message send 作为 cron 命令，会失败，因为 cron 环境不包含 NVM 的 node 路径。

错误示例：

1
0 * * * * openclaw message send ...  # ❌ 会静默失败

正确做法： 用 bash -l -c 包装，加载完整用户环境

1
0 * * * * /bin/bash -l -c "openclaw message send --channel feishu --target <chat_id> --message '内容'" 2>&1 | logger -t tag

2.2 我的 crontab 配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 每小时模型检查（已改为每天12:00）
0 12 * * * /bin/bash -l -c "openclaw message send --channel feishu --target ou_xxx --message '🕐 每日模型检查：正常'" 2>&1 | logger -t model-check

# 早间新闻（8:30）
30 8 * * * /bin/bash -l -c "openclaw message send ..." 2>&1 | logger -t morning-news

# 晚间AI新闻（21:00）
0 21 * * * /bin/bash -l -c "openclaw message send ..." 2>&1 | logger -t evening-news

# 每日收益报告（23:00）
0 23 * * * /bin/bash -l -c "openclaw message send ..." 2>&1 | logger -t revenue-report

# 工作日报（18:00）
0 18 * * * /bin/bash -l -c "openclaw message send ..." 2>&1 | logger -t daily-progress

关键点：

  • 使用绝对路径：/bin/bash -l -c "命令"
  • 2>&1 | logger -t tag 将输出重定向到系统日志，便于排查
  • 测试时先用 openclaw message send 手动运行确认成功，再加到 crontab

三、模型维护自动化脚本

我写了一个 model-maintenance.sh 脚本，定期检查 config.yaml 中配置的模型是否在最新的免费模型列表中，并推送报告。

3.1 脚本位置

/Users/zhaojingzhou/.openclaw/workspace/scripts/model-maintenance.sh

3.2 脚本逻辑

  1. 读取 config.yaml 中的模型列表
  2. 与已知的 28 个 OpenRouter 免费模型对比
  3. 识别可能失效或过时的模型
  4. 生成健康报告并推送
  5. 记录日志

3.3 核心代码片段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
set -e
LOG_FILE="/path/to/model-maintenance.log"
CONFIG_FILE="/Users/zhaojingzhou/.openclaw/config.yaml"
DATE=$(date '+%Y-%m-%d %H:%M:%S')
ISSUES_FOUND=0

# 读取配置的模型
CONFIG_MODELS=$(grep -E "^\s*-\s+" "$CONFIG_FILE" | sed 's/^\s*-\s*//' | grep -v '^#' | tr '\n' ' ')

# 已知免费模型列表（2026-03）
ALL_FREE_MODELS="openrouter/free openrouter/hunter-alpha ..." # 完整28个

# 检查每个模型
for model in $CONFIG_MODELS; do
    if echo "$ALL_FREE_MODELS" | grep -q "$model"; then
        echo "[$DATE] ✅ $model: in free list"
    else
        echo "[$DATE] ❌ $model: NOT in free list"
        ISSUES_FOUND=1
    fi
done

# 推送报告
MESSAGE="...（格式化报告内容）"
openclaw message send --channel feishu --target <chat_id> --message "$MESSAGE" 2>&1 | tee -a "$LOG_FILE"

3.4 使用方式

1
2
3
4
5
# 手动执行
./scripts/model-maintenance.sh

# 或加入 crontab（每天12:00执行）
0 12 * * * /bin/bash -l -c "/Users/xxx/workspace/scripts/model-maintenance.sh"

四、实际排查案例：cron 任务不执行

问题现象

  • crontab 有配置，但从未收到推送消息
  • 手动执行命令正常

排查过程

  1. 检查 crontab 列表：

    1
    crontab -l

    确认任务存在且时间正确。

  2. 检查系统日志：

    1
    sudo log show --predicate 'eventMessage contains "model-check"' --last 1h

    查看 logger 是否有输出。

  3. 核心发现：
    cron 运行时没有 NVM 环境，openclaw 依赖的 node 不在 PATH 中。

  4. 解决方案：
    将命令改为：

    1
    0 * * * * /bin/bash -l -c "openclaw message send ..." 2>&1 | logger -t model-check

    -l 表示 login shell，会加载 ~/.bash_profile 或 ~/.zprofile，从而引入 NVM 的路径。

五、完整自动化架构建议

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
┌─────────────────────────────────────────────┐
│          OpenClaw 自动化架构                │
├─────────────────────────────────────────────┤
│ 1. 模型健康检查 (model-maintenance.sh)    │
│    - 频率：每天12:00                        │
│    - 推送：配置健康报告                     │
│    - 日志：/logs/model-maintenance.log     │
│                                            │
│ 2. 定时消息推送 (crontab + openclaw)      │
│    - 模型检查：每天12:00（已改）            │
│    - 早间新闻：每天8:30                    │
│    - 晚间新闻：每天21:00                   │
│    - 收益报告：每天23:00（待完善内容）      │
│    - 工作日报：每天18:00                   │
│                                            │
│ 3. 被动心跳 (heartbeat-state.json)        │
│    - 用户每次交互时自动检查模型可用性      │
│    - 超过1小时未检查则静默更新 MEMORY.md   │
│                                            │
│ 4. 日志与监控                             │
│    - 系统日志 logger 捕获所有 cron 输出    │
│    - 本地日志 /logs/*.log                 │
│    - MEMORY.md 记录关键变更                │
└─────────────────────────────────────────────┘

六、最佳实践与提醒

  1. 永远用 bash -l -c 包装 openclaw 命令

    • 避免环境变量问题
    • 确保 NVM node 可用

  2. 测试顺序：

    • 手动执行成功 → 加入 crontab → 观察日志 → 验证推送

  3. 日志管理：

    • 任务输出重定向到 logger
    • 脚本内部用 tee -a 记录本地日志

  4. 推送内容：

    • 简洁、具体、可操作
    • 避免空洞的”进展：进行中”
    • 包含量化指标和下一步计划

  5. 配置管理：

    • 修改 config.yaml 后立即更新 MEMORY.md 记录
    • 模型列表 Keeping 与最新公开数据同步（每月一次）

结语

自动化是 OpenClaw 高效运转的基石。正确配置 cron 环境、编写健壮的维护脚本、建立监控体系，能让你的 AI 助手 24/7 稳定运行，及时发现问题并推送告警。

如果遇到类似 “cron 任务不执行” 的问题，优先检查环境变量和 PATH，用 bash -l -c 包装命令几乎总能解决。

附录：我的 crontab 当前配置（2026-03-14）

1
2
3
4
5
0 12 * * * /bin/bash -l -c "/Users/zhaojingzhou/.nvm/versions/node/v22.22.0/bin/openclaw message send --channel feishu --target ou_985eeb07a18725cf9b5d5d9ae63a324d --message '🕐 每日模型检查（12:00）：当前所有28个免费模型正常，stepfun/step-3.5-flash:free 仍为 #1。使用量: 1.26T tokens。'" 2>&1 | logger -t model-check
30 8 * * * /bin/bash -l -c "openclaw message send --channel feishu --target ou_985eeb07a18725cf9b5d5d9ae63a324d --message '🌅 早上好！今日热点新闻已更新。使用 exa-web-search-free 搜索最新资讯。'" 2>&1 | logger -t morning-news
0 21 * * * /bin/bash -l -c "openclaw message send --channel feishu --target ou_985eeb07a18725cf9b5d5d9ae63a324d --message '🌙 晚间AI/科技热点新闻：使用 exa-web-search-free 搜索今日最新AI/科技资讯。'" 2>&1 | logger -t evening-news
0 23 * * * /bin/bash -l -c "openclaw message send --channel feishu --target ou_985eeb07a18725cf9b5d5d9ae63a324d --message '💰 今日收益报告：检查所有创收渠道，汇总今日收益。'" 2>&1 | logger -t revenue-report
0 18 * * * /bin/bash -l -c "openclaw message send --channel feishu --target ou_985eeb07a18725cf9b5d5d9ae63a324d --message '📊 工作日报（18:00）：今日进展：进行中...'" 2>&1 | logger -t daily-progress

本文基于真实部署经验整理，转载请注明出处。

发表更新踩坑记录6 分钟读完 (大约825个字)

MySQL多字段排序的问题

最近在一次开发过程中发现了一个问题，我们都知道MySQL在Order By的时候可以指定多列，会按照指定的顺序依次排序。

例如指定A,B,C列，MySQL会先按A排序，如何A值相同的再按B排序，B值相同的再按C排序。

然后其中还是有不少门道的，例如我就碰到了如下问题，我有一个表test，表结构如下：

1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE `test` (

`A` varchar(128) NOT NULL COMMENT 'A',

`B` varchar(64) NOT NULL COMMENT 'B',

`C` varchar(64) NOT NULL COMMENT 'C'

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='TEST'

其中有如下数据：

A B C
C料 12321 123
c料 测试 SPHC
c料 测试 SPHC
C料 测试 测试
C料 测试 测试

接着执行如下查询

1
2
3

select * from test order by A,B,C

按照我们上面的说法最后出来的结果应该是：

A B C
C料 12321 123
C料 测试 测试
C料 测试 测试
c料 测试 SPHC
c料 测试 SPHC

然而实际出来而结果是：

A B C
C料 12321 123
c料 测试 SPHC
c料 测试 SPHC
C料 测试 测试
C料 测试 测试

可以看到的是A列明显乱序了（注意C大小写），不是说好A相同的排序在一起呢，怎么看起了不对了。

既然是按照列的顺序一个一个排序的，那我们就一个一个排除，看看到底是在哪一列排序出了问题。

执行如下查询：

1
2
3

select * from test order by A,B

得到如下结果：

A B C
C料 12321 123
C料 测试 测试
C料 测试 测试
c料 测试 SPHC
c料 测试 SPHC

也就是说在C列加入排序之前，A还是看着有序的，那到底是怎么回事呢？注意回到最开始我们说的MySQL的排序规则，A相同再按B排，B相同按C排。

所以C在加入排序之前，MySQL认为A，B排序后有相同的结果，也就是c料,测试=C料,测试了，所以C加入排序之后可以在前者相同的排序结果中在按C排序。

于是就产生了看起来错误的顺序，这是因为创建表的时候，没有对字段A，B，C指定collation（MYSQL排序依据），默认会使用对应字符集的Collation，

我这里字符集是utf8mb4，对应的默认collation通常是utf8mb4_general_ci，这个collation是大小写不敏感的。

解决办法有两种：

1.更改字段的collation，

1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE `test` (

`A` varchar(128) NOT NULL COMMENT 'A' COLLATE utf8mb4_bin,

`B` varchar(64) NOT NULL COMMENT 'B' COLLATE utf8mb4_bin,

`C` varchar(64) NOT NULL COMMENT 'C' COLLATE utf8mb4_bin

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='TEST'

使用utf8mb4_bin，这个是大小写敏感的。

2.在排序的时候指定BINARY关键字

1
2
3

select * from test order by binary A,binary B, binary C

因为它会强制MySQL将字段作为二进制字符串对待。

由于这是一个历史存在的表，避免产生其它意向不到的结果，我使用了方法二。至此问题解决。

发表更新踩坑记录10 分钟读完 (大约1435个字)

记一次线上Spring和Dubbo死锁排查

问题

前不久线上发现有系统间数据没有同步，排查一通下来发现应该是 MQ 消息没有被消费，通过 MQ Console 发现，未被消费的消息全都集中的一台机器上（消息投放的queue 以及 rebalance 关系），此时我有两个怀疑，一是消费者线程挂了，二是此服务分配到的消息队列出了什么莫名的问题。由于正值业务高峰，领导第一时间重启了服务，重启后一切恢复正常。排查由于一些其它事项，也到此中断。

然而没过多久，我听到其它需求项目组在测试环境出现了相同的问题，也是消息不消费了，导致业务异常。我立马找到对应服务 dump 了线程。

我将 dump 文件通过 visualVM 打开，然后得到了很明显的提示：Found one Java-level deadlock:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
"ConsumeMessageThread_1":
  waiting to lock monitor 0x00007f1350390f18 (object 0x000000008024ebc0, a java.util.concurrent.ConcurrentHashMap),
  which is held by "main"
"main":
  waiting to lock monitor 0x00007f1330071f18 (object 0x0000000080fb6318, a org.apache.dubbo.config.deploy.DefaultModuleDeployer),
  which is held by "Thread-26"
"Thread-26":
  waiting to lock monitor 0x00007f1350390f18 (object 0x000000008024ebc0, a java.util.concurrent.ConcurrentHashMap),
  which is held by "main"

Java stack information for the threads listed above:
===================================================
"ConsumeMessageThread_1":
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:187)
        - waiting to lock <0x000000008024ebc0> (a java.util.concurrent.ConcurrentHashMap)
        at org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch(AbstractBeanFactory.java:486)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.doGetBeanNamesForType(DefaultListableBeanFactory.java:432)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:403)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:515)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:508)
        at org.springframework.context.support.AbstractApplicationContext.getBeansOfType(AbstractApplicationContext.java:1186)
        ...
        at org.apache.rocketmq.client.impl.consumer.ConsumeMessageConcurrentlyService$ConsumeRequest.run(ConsumeMessageConcurrentlyService.java:411)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
"main":
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.startSync(DefaultModuleDeployer.java)
        - waiting to lock <0x0000000080fb6318> (a org.apache.dubbo.config.deploy.DefaultModuleDeployer)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.start(DefaultModuleDeployer.java:139)
        at org.apache.dubbo.config.ReferenceConfig.get(ReferenceConfig.java:228)
        ...
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
        at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:588)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1173)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1067)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:513)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
        - locked <0x000000008024ebc0> (a java.util.concurrent.ConcurrentHashMap)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:761)
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
        - locked <0x00000000804b98b0> (a java.lang.Object)
        at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122)
        at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:693)
        at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:360)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:303)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1118)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1107)
        at com.internet.saasbillmanager.ApplicationMain.main(ApplicationMain.java:46)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:51)
        at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:52)
"Thread-26":
        at org.springframework.context.event.AbstractApplicationEventMulticaster.getApplicationListeners(AbstractApplicationEventMulticaster.java:185)
        - waiting to lock <0x000000008024ebc0> (a java.util.concurrent.ConcurrentHashMap)
        at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:128)
        at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:393)
        at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:347)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener.publishEvent(DubboDeployApplicationListener.java:91)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener.access$000(DubboDeployApplicationListener.java:47)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener$1.onStarted(DubboDeployApplicationListener.java:70)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener$1.onStarted(DubboDeployApplicationListener.java:62)
        at org.apache.dubbo.common.deploy.AbstractDeployer.setStarted(AbstractDeployer.java:121)
        at org.apache.dubbo.config.deploy.DefaultApplicationDeployer.onStarted(DefaultApplicationDeployer.java:989)
        at org.apache.dubbo.config.deploy.DefaultApplicationDeployer.checkState(DefaultApplicationDeployer.java:868)
        - locked <0x0000000080fa6c10> (a java.lang.Object)
        at org.apache.dubbo.config.deploy.DefaultApplicationDeployer.notifyModuleChanged(DefaultApplicationDeployer.java:851)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.onModuleStarted(DefaultModuleDeployer.java:264)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.startSync(DefaultModuleDeployer.java:171)
        - locked <0x0000000080fb6318> (a org.apache.dubbo.config.deploy.DefaultModuleDeployer)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.start(DefaultModuleDeployer.java:139)
        at org.apache.dubbo.config.ReferenceConfig.get(ReferenceConfig.java:228)
        at org.apache.dubbo.config.spring.ReferenceBean.getCallProxy(ReferenceBean.java:346)
        at org.apache.dubbo.config.spring.ReferenceBean.access$100(ReferenceBean.java:99)
        at org.apache.dubbo.config.spring.ReferenceBean$DubboReferenceLazyInitTargetSource.createObject(ReferenceBean.java:353)
        at org.springframework.aop.target.AbstractLazyCreationTargetSource.getTarget(AbstractLazyCreationTargetSource.java:86)
        - locked <0x0000000085b49868> (a org.apache.dubbo.config.spring.ReferenceBean$DubboReferenceLazyInitTargetSource)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:192)
       ...
        at com.xxl.job.core.thread.JobThread.run(JobThread.java:152)

Found 1 deadlock.

这里有 3 个线程：

  • “ConsumeMessageThread_1” MQ 消费者线程

  • “main”: 主线程

  • “Thread-26”: XXL-JOB 执行线程

其实主要是这两个线程引发的问题：

  • “main”: 主线程

  • “Thread-26”: XXL-JOB 执行线程

MQ 消费者线程是正好撞在枪口上了。

涉及两个锁：

  • DefaultModuleDeployer：object monitor lock

  • DefaultSingletonBeanRegistry.singletonObjects：object monitor lock

暂且将第一个称为 Dubbo 锁，第二个称为 Spring 锁。

“main”: 主线程做的事情是初始化一个基础服务（Dubbo Consumer）注册到 Spring 和 Dubbo 中， 而其先获取到了 Spring 锁，再去获取 Dubbo 锁。

“Thread-26”：job 线程是由 xxljob 触发后执行一个任务，需要调用一个远程的 Dubbo 服务，于是 先获取了 Dubbo 锁，再去获取 Spring 锁。

于是两个线程就互相锁死了，而 MQ 消费者线程，也要去Bean Container 中获取 Bean，也需要获取 Spring 锁，也就卡死了。

解决方案

这个问题由于是在启动过程中发生，所以我设想了两个解决方案（没有好的契机去解决这个问题，只能等到有相关需求了），其实思路是同一个，那就是将出问题的 Bean 给延迟加载：

  • 将“基础服务”Bean 给@Lazy。
  • 将“XxlJobSpringExecutor”在spring启动完成之后再注册进容器，避免启动过程中收到任务的执行命令。
发表更新踩坑记录5 分钟读完 (大约822个字)

老版本Dubbo的一个bug

线上有用户反应P 服务页面时不时就报个错，后来发现都涉及I服务的一个接口方法，这里暂且就叫F 接口。只是时不时报错，那说明可能是某些参数会导致异常，于是我开始查看日志，看看是不是有什么特殊参数导致隐藏 bug 被发现。
结果是报错和不报错的请求参数都一样，那是不是多台机器上运行的代码不一致呢？于是我看了F 接口的代码，发现最近没有迭代记录，而且所有机器上部署的代码均一致。
那有没有可能是环境问题？于是我上 Dubbo 控制台查看，发现 provider 和 consumer 都正常：
DubboAdmin
这个时候我开始有点懵逼了😅。

我又想到，如果是一直存在问题，那么不可能到今天才有用户反馈，所以还是跟近期的什么操作有关。于是我开始排查最早是什么时间出现的问题，发现是 10 月 10 日的 18:00:03，又发现F 接口所在的I服务在10 月 10 日的 17:57:28有过发布记录。
release

这下就有点奇怪了，就算I服务所有机器同时发布，可能也就是报一会 no providers错误啊，更不用说是滚动发布的，加上 dubbo 的 failover不会一直报错的啊。

就在这时我看到了一个关键的错误信息：（之前只看到了 NPE 没具体位置）：
Error

问题直指DubboInvoker:109。

我们 dubbo的版本是(2.6.6)，我拉下dubbo 代码发现这块的代码是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Override
public boolean isAvailable() {
    if (!super.isAvailable())
        return false;
    for (ExchangeClient client : clients) {
        //这一行是 109，就是这一行报错
        if (client.isConnected() && !client.hasAttribute(Constants.CHANNEL_ATTRIBUTE_READONLY_KEY)) {
            //cannot write == not Available ?
            return true;
        }
    }
    return false;
}

109 行报 NPE 莫非 client 是 null？带上猜测我开始看 client 是怎么来的，最终找到com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol#getSharedClient:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private ExchangeClient getSharedClient(URL url) {
        String key = url.getAddress();
        ReferenceCountExchangeClient client = referenceClientMap.get(key);
        if (client != null) {
            if (!client.isClosed()) {
                client.incrementAndGetCount();
                return client;
            } else {
                //3
                referenceClientMap.remove(key);//4
            }
        }

        locks.putIfAbsent(key, new Object());
        synchronized (locks.get(key)) {//2
            if (referenceClientMap.containsKey(key)) {
                return referenceClientMap.get(key);//5
            }

            ExchangeClient exchangeClient = initClient(url);
            client = new ReferenceCountExchangeClient(exchangeClient, ghostClientMap);
            referenceClientMap.put(key, client);
            ghostClientMap.remove(key);
            locks.remove(key);
            //1
            return client;
        }
    }

又是一段平平无奇的代码😅，看到这里有用到锁，说明开发者考虑到这里可能会存在并发调用。我又看了下日志，10 月 10 日的 18:00:03前后确实出现了并发调用的现象，难道是这里的并发控制有 bug？于是我开始思考各种场景，还真被我发现一种可能出问题的情况，下面我画了个图演示一下：

flow

最后 序号 5 处返回了一个 null 的 client。

由于2.6.6 版本已经有点老，指不定这个问题已经有人提过，于是我到 github 一番搜索，结果找到了另外一个问题：https://github.com/apache/dubbo/issues/6444

这块dubbo 后面也迭代了好几次，已经搞不清楚了。

最后，重启大法好！

发表更新3 分钟读完 (大约475个字)

关于 java 中的可用内存问题

最近看了《why 技术》的一篇文章《这个队列的思路是真的好，现在它是我简历上的亮点了。》。本来没什么问题，觉得这么好的东西不拿来用一用太可惜了。于是我就搞到了项目中，但是却发现一个问题，文中提到的：

1
2
MemoryUsage heapMemoryUsage = MX_BEAN.getHeapMemoryUsage();
long availableMemory = heapMemoryUsage.getCommitted();

我发现availableMemory在一段时间内没什么变化。

我是这么测试的：

1
2
3
4
5
6
7
8
9
10
public static void main(String[] args) throws InterruptedException {
       List<byte[]> objects = new ArrayList<>();
       long _1MB = 1024 * 1024;
       while (true) {
           MemoryUsage heapMemoryUsage = MX_BEAN.getHeapMemoryUsage();
           System.out.println("committed:"+heapMemoryUsage.getCommitted()/_1MB);
           objects.add(new byte[1024 * 1024 * 50]);
           Thread.sleep(100L);
       }
   }

讲道理应该实时变化才对，后来我点进去了why哥留下的PR链接，发现这个PR在2022-06-06有一个提交：
1
备注信息为:”fix bug”，具体的修改为：
2
可以看到原来通过MemoryUsage获取可用内存变成了：

1
Runtime.getRuntime().freeMemory()

也就是说之前使用的getCommited()获取的并不是可用内存，于是我看了下MemoryUsage的源码(jdk8)，哈哈哈😂，发现图示的很清楚：
3
真正的可用空间是committed - used，于是我又做了下面的测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
public static void main(String[] args) throws InterruptedException {
       List<byte[]> objects = new ArrayList<>();
       long _1MB = 1024 * 1024;
       while (true) {
           MemoryUsage heapMemoryUsage = MX_BEAN.getHeapMemoryUsage();
           long freeMemory = Runtime.getRuntime().freeMemory();
           System.out.println("freeMemory："+freeMemory/_1MB);
           System.out.println("committed:"+heapMemoryUsage.getCommitted()/_1MB);
           System.out.println("committed - used:"+(heapMemoryUsage.getCommitted()-heapMemoryUsage.getUsed())/_1MB);
           objects.add(new byte[1024 * 1024 * 50]);
           Thread.sleep(100L);
       }
   }

4

可以看到确实如此。

20220615更新

why哥给我回复了，这个问题大佬也讨论过https://github.com/apache/dubbo/pull/10021#issuecomment-1147464751

其中一个大佬说的可用内存应该是：

1
MemoryUsage#getMax() - MemoryUsage#getUsed()

然后我在 github 上回复了一下大佬，大佬给我的答复是：
5

发表更新Java随记3 分钟读完 (大约477个字)

什么?Lombok有坑?

事情是这样的，前段时间有个线上bug需要我去排查：
1

首先看了CAT的调用链，并没有发现什么问题，所有的服务都是正常处理结束。

于是我要了一个traceId，去排查日志，也是没有发现什么问题。

我拉下了生产版本的代码，走查了一下逻辑，并没有发现什么大问题，所以这注定是一个细节问题。

由于这是一个可以复现的问题，所以让测试大佬在测试环境模拟了下有问题的数据，于是我开始Debug了。

一行一行代码的看，一个一个变量的watch，最终发现了问题。

2

首先是同事新增了如下代码：

3

然后数据的OwnerId都是null：

4

紧接着执行了这个removeAll:

5

可是这为什么会出问题呢？

原来是list中的对象，是同事新加的，继承了原有的对象：

6

并且使用了Lombok的Data注解。这个注解会生成equals方法：

7

removeAll是调用的equals判断对象是否相同，equals方法重写后，导致只要这两个对象的ownerId都为空就会认为相同。

可以看到一个@Data注解相当于加了6个注解：

8

怎么解决这个问题呢？既然问题出在equals，那么有没有什么办法让子类生成的equals中也能包含基类的属性呢？

是有的：

1
@EqualsAndHashCode(callSuper = true)

加上这个注解就可以了。

可以看到@Data注解做的事情太多了，会发生你意想不到的情况，实际是不太推荐无脑使用的，建议还是自己组合需要的注解。

发表更新工具分享6 分钟读完 (大约870个字)

Spotlight替代工具uTools及插件分享

Mac自带的Spotlight对于普通用户来说已经够用了，高阶一点的会使用alfred来增强，但是alfred交互方式比较单一，通常是列表方式，也不支持通过输入内容匹配wf，通常需要keyword唤醒。而且alfred是收费软件。

uTools

uTools 也是一款Spotlight增强应用，默认的唤醒快捷键是option+space，墙裂推荐改为double command。应用的主界面长这样：

uTools应用的逻辑有点像微信小程序，可以通过keyword呼出小程序，也可以通过剪切板内容自动识别出来。

阅读更多
发表更新Java随记8 分钟读完 (大约1170个字)

Dubbo调用超时那些事儿

其实之前很早就看过dubbo源码中关于超时这部分的处理逻辑，但是没有记录下来，最近在某脉上看到有人问了这个问题，想着再回顾一下。

开始

从dubbo的请求开始，看看dubbo（2.6.6）在超时这块是怎么处理的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel#request(java.lang.Object, int) 
 @Override
    public ResponseFuture request(Object request, int timeout) throws RemotingException {
        if (closed) {
            throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");
        }
        // create request.
        Request req = new Request();
        req.setVersion(Version.getProtocolVersion());
        req.setTwoWay(true);
        req.setData(request);
        DefaultFuture future = new DefaultFuture(channel, req, timeout);
        try {
            channel.send(req);
        } catch (RemotingException e) {
            future.cancel();
            throw e;
        }
        return future;
    }
阅读更多
发表更新Java随记4 分钟读完 (大约576个字)

Java双亲委派机制的妙用

最近在项目中看到一段通过easyexcel导出动态表头的实现，开始我以为是easyexcel官方的实现，其中有这样一段代码：

1
2
3
4
5
6
7
8
//将动态表头上传至ThreadLocal
saveToThreadLocal(clz, result);

private <T> void saveToThreadLocal(Class<T> clz, List<String> result) {
        Map<Class,List<String>> paramMap = new ConcurrentHashMap<>();
        paramMap.put(clz, result);
        ThreadLocalUtil.FIELD_CACHE_MAP.set(paramMap);
}
阅读更多
发表更新踩坑记录11 分钟读完 (大约1694个字)

同事问了我一个关于RocketMQ的问题

同事突然问我：RocketMQ的一个消息，多次消费重试，消息的msgId会不会变？哪怕已经进了DLQ。

刚开始出于经验，我说不会变。因为我之前每次排查问题的时候，用同一个msgId都能找到多次重试消费的日志。后来为了更加确定，我卷了一下源码，我看的是4.6.1，一是因为公司用的这个版本，二是我上次卷的就是这个版本。。。

消息重试

既然跟重试有关，那就从客户端消费失败的逻辑开始，看看能不能找到蛛丝马迹，下面是消费失败将消息发回broker的代码：

阅读更多
关注我

链接

分类

归档

最新文章

标签

ASM1
Activiti1
BUG2
Bug1
CAP1
CPU1
Chrome1
DeadLock1
Deadlock1
Docker3
Dubbo3
EPUB1
Golang8
IDEA1
IRIW1
Java27
Lombok1
Maven1
MessageId1
MongodDB2
MySQL5
Mybatis1
OCR1
OpenClaw1
PDF1
Paxos1
Python3
RPC1
RocketMQ2
Spotlight1
Spring2
UniqKey1
VSCode1
dubbo1
elasticsearch1
flume1
kafka2
launchctl1
linux1
uTools1
volatile1
一致性1
博客1
双亲委派1
可用内存1
图床1
定时任务2
并发1
开源1
效率1
模型管理1
死锁1
爬虫1
电子书1
自动化1

follow.it

×