heavyrain.lee

> 还有你们的环境是什么情况，是什么操作系统，jdk的版本是什么 这个是什么情况，特别是jdk的情况？

这个没有关系，可以不用管

> 根据之前邮件沟通的情况，可能是堆外内存泄漏导致的，启动命令加上 -Dio.netty.leakDetectionLevel=advanced 看看有没有堆外泄漏的日志。 查一下这几天的所有日志，搜索一下 LEAK 看看有没有这个字段

你可以查一下netty堆外内存泄漏相关信息，如果开启了上面那个开关，在第一次泄漏时会打印，但后面不会再打印，所以需要找一下最早的那些日志。CPU明显比之前高应该是这个开关在工作

你们有没有动过jvm的参数？

从前面提供的jmap信息看，实际占用物理内存远大于jvm内存，只能怀疑是堆外内存的泄漏，可以在下次重启时，按照 https://blog.csdn.net/fxh13579/article/details/104754340/ 这个说明抓一下 NMT信息

加上下面这2个参数试试 ``` OTHER_LDFLAGS = ( "-ld_classic", "-Wl", ); ```

原因是客户端先拉回消息生成会话列表，然后再同步设置，设置中包含删除会话的信息，这时候再删除被标记删除的会话，这样在UI上就会先显示所有的历史会话，然后再闪一次去掉之前删除的会话。 因为协议栈同步机制无法修改，所以如果要想避免这种情况只能UI上改，同步设置会在连接状态变成1之前完成，所以方法1，在连接状态变成1时才进入到会话列表，这个时候已经同步完成的，问题是如果数据量比较大会等待较长时间；方法2是在会话列表这里，只有连接状态变成1之后才显示，同样也是不能让用户快速看到会话列表

上面提到的修复方法都是有代价的，会牺牲展示会话列表的时间，我们这边认为付出的代价换取到的收益（解决闪一下的问题）是不值得的，所以我们这边是不能这样处理的。建议你们可以保持现状，这个闪一下的问题并不严重

第一个问题是sdk的问题，请联系我们更新sdk。第二个问题是UI层状态刷新的问题，在会议的状态变成connected时更新一下UI就好了，请参考我们最近的提交