前提：客户端和服务端基于websocket进行交互，客户端每隔8s发送心跳，服务端检测心跳，超过三分钟没收到会关闭session。
现象：客户端日志记录发送了心跳消息，服务端没收到心跳，超时后服务端关闭sessionA，客户端新建了会话sessionB，过了会又收到了之前sessionA的消息，由于sessionA已经关闭，所以isOpen 方法返回 false。
最开始并没有关注到sessionA在关闭后收到的消息，所以一直以为是丢消息了，服务端说是客户端的问题，客户端说明明发送了消息，日志都记录了。
当然现有消息交互方式也是有问题的，客户端记录发送成功，并不表明真的成功了，所以靠谱的应该是加上业务层的ack，客户端收到服务端的业务ack才真正的是表明消息发送成功了。现在介绍为什么会出现上面的现象。
客户端跟服务端是单会话形式，所以被@OnMessage标注的方法会依次触发，什么意思？客户端A往服务端发送了1、2、3三个消息，服务端先处理1、处理完之后才会处理2，然后是3。当然了，session之间是并发的，互不影响，只是session内消息是一条一条执行。问题就在这，如果消息1执行很慢，时间超过3分钟，而心跳消息2、3...由于得不到处理就会触发超时关闭session。
结论：消息并没有丢，而是由于消息处理时间太久，导致后续消息得不到执行，程序判断心跳超时 关闭了session。原因找到了，怎么处理就比较容易了。