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或加锁,别裸奔。

作者最新文章
漫蛙漫画APP下载安卓版免费
2026-10-13 13:42
漫蛙动漫下载安卓版安装包
2026-10-13 13:19
漫蛙manwa2免费漫画入口在哪
2026-10-13 13:17
漫蛙2漫画入口
2026-10-13 13:03
会声会影X5去除视频原有字幕的操作方法
2026-10-13 11:07
热门文章
更多
精品专题
更多
Mac软件
更多
WINDOWS
更多










































