QuickFIX/J session API logon()调用失败原因排查及解决方法问询

• 无效Session对象残留：首次创建Session后立即断开时，底层Socket/IO流已经被关闭触发EOF，但Session登出的清理逻辑未同步将对应sessionId从存储Map中移除，残留的Session对象持有的是已经终止的IO流。调用logOn()方法时，框架会先校验IO可用性，检测到流已经处于EndOfStream状态直接触发断开逻辑，流程提前终止，不会执行到自定义重写的logOn()代码。
• 方法执行前置拦截逻辑：多数网络通信框架的登录类方法执行前都会校验Session的连接状态，残留的Session对象的连接状态未同步更新为已断开，框架校验底层连接状态不满足执行条件时，会直接抛出EOF异常终止流程，跳过自定义logOn()逻辑。
• 存储竞态问题：Session存入Map的时机早于登出清理的执行时机，首次创建Session后立即触发断开登出时，先执行了Session写Map操作，后执行的登出逻辑未成功匹配到对应Session做删除，导致无效Session残留。

• 调用前加有效性校验：每次从Map中取出Session准备调用logOn()之前，先校验Session持有的IO流是否可用、连接状态是否为活跃，校验不通过的直接删除Map中对应sessionId记录，创建新的Session处理请求，不再复用无效对象。
• 完善生命周期清理钩子：在连接断开、登出事件的回调逻辑中，新增同步删除Map中对应Session的逻辑；如果是异步断开场景，增加原子操作或分布式锁保证Map增删的一致性，避免竞态导致的清理失败。
• 调整Session入Map的时机：不要在Session初始化完成后就立刻写入Map，等连接校验通过、自定义logOn()逻辑执行成功之后，再将Session存入Map，从根源上避免未就绪、已断开的无效Session进入存储。
• 新增定期清理机制：后台启动定时任务，遍历Map中所有Session，通过心跳检测、IO状态校验的方式筛选出长时间无响应、流已关闭的Session，做批量删除清理，避免残留的无效Session被后续请求命中。

内容的提问来源于stack exchange，提问作者S Shah