flock 怎样让定时脚本避免并发执行

让定时脚本避免并发执行，可以在业务开始前对一个固定文件获取 flock 独占锁，并让持锁的文件描述符覆盖整个任务。周期任务通常加 -n：上一轮仍占锁时，本轮立即跳过，避免不断堆积等待进程。所有需要互斥的启动入口必须使用同一个锁对象。

项目官方地址：https://github.com/util-linux/util-linux

例如每分钟生成一次报表，而一次计算偶尔需要超过一分钟。单纯缩短计算时间不能保证永不重叠；入口互斥可以限制同一时刻执行的实例数。下面按单机、本地文件系统和同一任务账户说明，不把本地文件锁当作多机协调方案，也不声称已有上线压测结果。

把锁放进所有入口共用的脚本

建议把下列包装脚本保存为 /usr/local/bin/report-once.sh。先由管理员准备一个仅任务账户可管理的锁目录 /var/lib/report-job/locks，并准备实际业务脚本 /usr/local/libexec/report-body.sh。示例不会代写报表业务；两个路径都需要按项目实际情况配置。

#!/bin/sh
# 固定路径必须由所有启动入口共用，父目录预先准备好
lock_file='/var/lib/report-job/locks/report.lock'

# 追加打开以避免无意义地截断文件；打开失败时禁止继续业务
exec 9>>"$lock_file" || {
    printf '%s\n' '无法打开报表锁文件' >&2
    exit 73
}

# 独占锁是默认模式；显式写 -x，-n 表示锁忙时不等待
if /usr/bin/flock -x -n 9; then
    :
else
    lock_status=$?
    if [ "$lock_status" -eq 1 ]; then
        # 此处检查的是单独的加锁命令，1 表示非阻塞锁冲突
        printf '%s\n' '已有报表任务持锁，本轮跳过'
        exit 0
    fi
    printf '加锁失败，退出状态：%s\n' "$lock_status" >&2
    exit "$lock_status"
fi

# 包装脚本等待业务结束，描述符9在此期间保持打开
/bin/sh /usr/local/libexec/report-body.sh
job_status=$?
exit "$job_status"

这里的任务包装脚本持有描述符9，它关联固定锁文件；业务脚本在包装脚本等待期间运行。把加锁单独写成一个判断，能把锁冲突与业务脚本自身返回 1 的情况分开。退出零表示这个包装策略接受“本轮跳过”，并不代表报表业务执行过。

cron 入口和手工入口都调用 report-once.sh，才能共享互斥范围。若手工直接运行 report-body.sh，就绕开了这层保护。flock 命令手册提供了按文件描述符加锁的接口说明；命令实际安装路径请按发行版调整。

cron 只负责触发，不再重复维护另一把锁

在任务账户的 crontab 中配置同一个包装脚本。日志目录和日志文件写权限也要预先准备。以下是调度配置示例，不是本机已经安装的任务：

# 每分钟触发包装脚本；锁忙时由包装脚本记录跳过
* * * * * /bin/sh /usr/local/bin/report-once.sh >>/var/log/report-job.log 2>&1

不要在 cron 使用一个锁文件，脚本里再使用另一个锁文件来表示同一互斥任务。那会增加需要理解的对象，手工入口也可能遗漏其中一层。统一包装脚本的好处，是以后改变锁策略时只改一处。

这个结构限制的是任务重叠，不会提高报表处理速度。若长期每轮都跳过，仍应关注任务耗时和触发频率。单实例也不保证业务恰好执行一次：任务可能未启动、执行失败或在写入中断后重试，业务自身仍需考虑重复处理的语义。

选择跳过还是等待，先明确任务语义

独占锁是共同的互斥方式，非阻塞请求和有界等待则是两种不同的争用策略。如果改用有界等待，应把包装脚本中的加锁行整体替换为 /usr/bin/flock -x -w 10 9，不要把 -n 与 -w 同时叠加来表达两个互相矛盾的意图。

任务记录至少要区分冲突状态与业务状态。使用命令包装形式时，子命令执行成功启动后，flock 会传回子命令的退出状态；因此即使通过 -E 自定义冲突码，也必须考虑业务退出码是否可能相同。本例把独立加锁命令与业务调用分开，避免仅凭一个混合退出码猜测原因。

锁文件留着，锁的生命周期看描述符

锁文件存在不表示任务正在运行。Linux 的 flock 锁关联打开文件描述，不是靠“文件存在”这个标记判断忙闲。相关描述符全部关闭时，锁会释放；继承描述符的子进程会影响这个生命周期。见flock 系统调用说明。

所以包装脚本正常退出以后，可以保留空的锁文件。不要在任务运行时删除并重建它：其他入口可能打开新文件对象，而原持锁实例仍关联旧对象，造成看似同名却未互斥的情况。也不要给业务加后台符号后让包装脚本立即结束；后台子进程是否继续继承描述符，会使锁寿命与预期更难对应。业务应保持前台，内部启动的关键子任务也应被等待。

普通本地文件系统上的锁通常需要各参与方主动遵守。一个完全不使用同一锁协议的进程，不会因此被禁止访问业务数据。固定文件、统一入口和一致的协议缺一不可。

什么时候需要换成其他协调方式

两个主机各自本地的同名路径，不能构成跨主机互斥。网络文件系统上的行为还受实现与挂载选项影响，不能直接套用本地结果；util-linux 手册专门提醒 NFS、CIFS 等环境存在限制。需要分布式单实例时，应按存储与故障模型选择协调机制。

落地时关注三类记录：业务完成与失败、锁冲突跳过、加锁本身失败。它们分别对应业务健康、调度压力和入口环境问题。没有实际测量时，不应凭一把锁宣称吞吐提高或故障消失。

上一轮崩溃后，要手动清理锁文件吗？

通常不需要。应区分遗留路径与仍被持有的锁；进程退出后是否还有相关子进程持有描述符，比文件是否存在更关键。

每分钟都要处理一份独立输入，跳过是否合适？

不一定。如果每次触发代表不能丢弃的独立工作项，应保存工作项并设计消费机制。flock 只负责互斥，不保存被跳过的工作。

能用共享锁让两个写任务一起跑吗？

共享锁允许多个共享持有者，不满足本文“同一时间只运行一个任务”的目标。这里使用独占锁，并让全部相关写入口遵守同一规则。