Java在线人数统计核心是准确识别用户上下线与活跃状态，单机可用HttpSession监听，Web端推荐心跳机制，分布式必须用Redis共享存储并配合过期策略。
Java系统中实现在线人数统计和用户在线状态管理，核心在于准确识别“谁在什么时候上线、是否还活跃、何时下线”。不依赖第三方中间件也能做，但要注意会话生命周期、异常掉线、分布式场景等关键问题。
基于HttpSession的简单在线统计（单机适用）
利用Servlet容器（如Tomcat）的HttpSession监听机制，是最轻量的入门方案。用户登录成功后创建session，通过监听器感知上下线。
- 实现
HttpSessionListener接口，在sessionCreated()中将用户ID或session ID加入全局计数器（如ConcurrentHashMap） - 在
sessionDestroyed()中移除对应记录，并减计数 - 注意：用户关闭浏览器、网络中断、未主动登出等情况，session不会立即销毁——需配合
maxInactiveInterval（默认30分钟）和定时清理逻辑 - 示例：用
static AtomicInteger onlineCount = new AtomicInteger(0)做总数，用ConcurrentMap存明细（key为sessionId，value为用户信息）
基于心跳机制的实时在线状态（推荐用于Web端）
前端每隔15–30秒发一次心跳请求（如/api/heartbeat），后端更新该用户的最后活跃时间。这是判断“当前是否在线”最可靠的方式。
- 后端维护一张内存表（如
ConcurrentMap），key为用户ID，value为最后一次心跳时间戳 - 提供一个
/api/online-count接口，遍历map，过滤掉“最后心跳超时（如>60秒）”的用户，返回剩余数量 - 可扩展：把用户信息（昵称、设备、IP）也存进map，支持在线列表展示
- 前端记得在页面卸载（
beforeunload）或登出时主动调用/api/logout清除状态，提升及时性
分布式环境下的统一在线状态（多节点部署必备）
单机内存方案在集群下失效。必须引入共享存储，常见选择是Redis。
餐饮E站通-在线订餐系统 免费版
下载
在线订餐系统源码,提供给设计人员参考一个小型的在线订餐管理系统源码，采用三层模式开发，代码注释详细前台可以进行用户注册、菜单管理及订餐后台管理员可以进行菜单管理、新闻管理、菜肴管理、用户管理操作数据库采用的是Sql2005（由于数据库在App_Data下，如果装了Sql2005数据库会自动配置）
立即学习“Java免费学习笔记（深入）”；
- 用户登录后，写入Redis：
SETEX user:1001:online "1" 120（120秒过期，代表心跳周期） - 每次心跳更新key的过期时间：
EXPIRE user:1001:online 120 - 统计在线数：
KEYS user:*:online效率低，改用SCAN或更优方式——给所有在线key打上同一前缀，用PFADD online_hll {userId}+PFCOUNT online_hll做基数估算（适合海量用户） - 或者用Redis Set：
SADD online_users 1001+EXPIRE online_users 120不行（Set本身不支持整体过期），应为每个用户单独设key，再用SCAN匹配+校验TTL
补充细节：避免误判与提升体验
真实业务中，几个容易忽略但影响准确性的点：
-
多端登录处理：同一用户在手机、PC同时登录，算1人还是2人？通常按用户ID聚合，不是按session；若需区分设备，可拼接
userId_deviceId作为唯一key - 自动踢出与并发登录控制：登录时先删旧session key，再写新key，保证只保留最新一次登录状态
- 离线消息兼容：如果系统有IM模块，可复用同一套心跳+Redis结构，让“在线状态”服务化，供其他模块订阅
- 后台管理页刷新频率：不要每秒轮询在线数，建议10–30秒一次，避免无谓压力
基本上就这些。从单机监听到分布式心跳，本质都是围绕“活跃性定义”和“状态存储一致性”展开。选型看规模：小系统用session监听+定时清理够用；中大型务必上Redis，配合心跳+过期策略，再加一层缓存降级（比如本地Caffeine兜底最近1分钟数据），就比较稳了。
