system.currenttimemillis() 适合轻量低频心跳调度，应通过时间差判断而非固定sleep，需防时间回拨、解耦业务逻辑，并避免用于亚秒级精准场景。
用 System.currentTimeMillis() 做任务调度心跳，本质是靠时间戳轮询判断是否该执行，适合轻量、低频、不依赖高精度的场景，比如服务健康上报、本地定时重试、简易状态刷新等。
心跳间隔控制：用差值代替固定 sleep
不要用 Thread.sleep(5000) 硬等，容易因处理耗时导致周期漂移。推荐记录上一次执行时间，每次循环计算已过时间：
- 定义 long lastHeartbeat = System.currentTimeMillis();
- 循环中取当前时间 current = System.currentTimeMillis();
- if (current - lastHeartbeat >= 5000) { 执行心跳逻辑; lastHeartbeat = current; }
这样即使某次处理花了 800ms，下次仍会在第 5 秒整点附近触发，节奏更稳。
避免时间回拨风险：简单兜底判断
系统时间可能被手动调整或 NTP 校正，导致 currentTimeMillis() 突然变小。若不做防护，可能误判“已过期”而高频触发：
MiniMax 媒体生成
下载
一款AI音频处理工具，主要用于MiniMax统一媒体生成技能，用于TokenPlan工作流。当用户要求生成音频、语音、TTS、旁白、图片、插图、姿势等媒体内容时使用，适合需要提升相关任务效率的用户。
- 保存上次时间戳时，同时记录一个递增序号（如 AtomicInteger）
- 检测到 current 1000ms，视为可疑回拨
- 此时跳过本次心跳，或仅记录告警，不执行业务逻辑
与业务逻辑解耦：心跳只负责“唤醒”，不承担执行
心跳线程应尽量轻量，只做信号触发，具体任务交给线程池或事件队列：
- 心跳检测通过后，调用
executor.submit(() -> doHealthCheck()) - 避免在心跳循环里直接调远程接口或写磁盘，防止阻塞后续心跳
- 可加简单开关（AtomicBoolean）控制启停，方便测试和运维干预
精度与替代建议：什么时候不该用它
System.currentTimeMillis() 分辨率通常为 10–15ms（取决于 OS），无法满足亚秒级精准调度：
- 要求误差 ScheduledThreadPoolExecutor
- 需支持暂停/恢复/动态修改周期的场景，建议用 Quartz 或 XXL-JOB
- 分布式环境下各节点独立心跳，需配合 Redis 等共享状态判断整体可用性
不复杂但容易忽略细节。
