System.currentTimeMillis记录用户最后操作时间

System.currentTimeMillis() 这个 API 太常见了，但坑也不少。说到底，它只是一个毫秒级的时间戳，不带任何业务含义，怎么用、在哪用、用的时候注意什么，都需要结合场景仔细掂量。下面几个关键原则，值得认真梳理一遍。

记录时机要明确

不能只在登录那一下刷个时间，然后就不管了；反过来，也没必要每个 HTTP 请求都去抢着更新时间戳，那样太浪费了。关键在于，什么时候记录才合适？

• 用户真正“干活”的时候——点击按钮、提交表单、切换页面，这些后端收到请求后顺手更新一下，合情合理。
• 心跳类请求，比如每 30 秒发一次 ping，也可以更新，但得设个门槛。建议加个简单校验，比如强制前后两次间隔至少 10 秒，免得被高频刷写打爆。
• 静态资源访问、日志打印、缓存读取这些非用户主动行为，就别掺和了，更新了也没意义。

存储位置要匹配场景

时间戳存到哪里，取决于你对可用性和一致性的胃口有多大：

• Session 里：简单直接，适合单机或者粘性负载均衡的场景。但一旦上了集群，就得考虑 Session 共享的问题，比如借助 Redis 搞定。
• 数据库用户表：加个 last_active_time 字段，强一致性首选。但高频更新下，数据库的压力是个现实问题，需要评估。
• Redis 哈希结构：比如用 user:123:status 存 {last_active: 1717023456789}，高性能、天然支持过期，非常适合实时在线状态的判断。

使用时别忽略时区与精度问题

System.currentTimeMillis() 返回的是自 1970-01-01 UTC 以来的毫秒数，本身与时区无关，但很多人栽在这上面：

• 做“超时判断”（比如 30 分钟无操作视为离线），直接用 long 相减：if (now - lastActive > 30 * 60 * 1000)，干净利落。
• 展示给用户时，再按本地时区格式化。存储层别碰时区，一碰就容易乱。
• 避免和 new Date() 或 LocalDateTime.now() 混用比较——后者可能受系统默认时区影响，对比结果可能让你怀疑人生。

注意并发更新安全

多个请求可能同时写最后操作时间，虽然通常不需要强一致，但得防一手异常覆盖：

• 用原子操作：Redis 的 SET user:123:last_active 1717023456789 天然幂等，省心。
• DB 更新带个条件：UPDATE user SET last_active_time = ? WHERE id = ? AND last_active_time < ?，避免旧请求覆盖新值。
• 如果测试或轻量场景下用内存 Map 暂存，记得上 ConcurrentHashMap 或加锁，别裸奔。