System.currentTimeMillis记录用户最后操作时间
作者:NorthPath
时间:2026-06-27
来源:互联网
浏览:0
记录用户最后操作时间需明确时机(用户主动行为时更新,心跳请求设间隔限制),存储可选Session、数据库或Redis,使用时区无关的UTC毫秒数做超时判断,并注意并发更新安全(原子操作或条件更新)。
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或加锁,别裸奔。

作者最新文章
贵州省住建厅与贝壳集团签署旅居战略合作:五大维度落地方案解析
2026-09-08 18:13
上海链家安住APP:业主主动卖房功能与成交数据解析
2026-09-08 18:11
如何批量将PPT转成PDF格式?PPT转PDF工具怎么选?
2026-09-04 16:03
PDF文件怎么压缩?3个小技巧帮你减小体积
2026-09-03 18:03
小批量试产总结报告:新产品量产导入评审实战指南
2026-09-02 19:48
热门文章
更多
精品专题
更多
Mac软件
更多
WINDOWS
更多
Windows 10
Windows
Windows 10 是一款微软推出的经典操作系统,拥有硬件兼容性与多任务处理能力。它更偏向把系统状态查看和常用调节动作放在一起,适合需要持续观察和微调设备状态的场景。
极度公式
Windows/macOS/Linux
极度公式是一款跨平台专业LaTeX公式识别编辑软件,支持OCR公式识别和多平台编辑。和使用说明,避免使用,享受完整功能与稳定支持。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。
















