[已回复] 求助MobileIMSDK在网络不通时，长时间运行出现OOM内存溢出的问题

exception:java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
crashMD5:c925fa212a171342c0c150835da33b3c
crashDump:{java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
    at java.lang.Thread.nativeCreate(Native Method)
    at java.lang.Thread.start(Thread.java:730)
    at com.imapp.mobileimsdk.android.core.LocalUDPDataReciever.startup(LocalUDPDataReciever.java:87)
    at com.imapp.mobileimsdk.android.core.AutoReLoginDaemon$1$1.onPostExecute(AutoReLoginDaemon.java:85)
    at com.imapp.mobileimsdk.android.core.AutoReLoginDaemon$1$1.onPostExecute(AutoReLoginDaemon.java:61)

部分日志如上。

场景： app在前台运行长达七八小时时，就出现了内存溢出。下班前，打开app，保持屏幕一直常亮，第二天早上来app已经崩掉。

分析：1 app其他地方也在创建线程导致MobileIMSDK重连出现oom。
           2 内存泄露导致oom？

请问各路大神从哪里入手解决这个问题？

APP能在前台长亮运行7、8个小时？你这不是普通用的用户场景吧。

是运行在专门的设备上的吗？

我看懂你的问题了。针对你这个情况，我来改一改代码，你帮我在你这台设备上做实验。

你一定要确保，你用我改过的最新代码运行的（你可以在下面我给你的代码里加入System.out这样的Log输出，确保是运行了修改后的代码）。

【1】你找到我下方截图的这个类里的这个方法：


【2】将上图里的方法，用我下面的代码完全覆盖，然后你重新运行：

        private void udpListeningImpl() throws Exception
        {
                while (true)
                {
                        // 缓冲区
                        byte[] data = new byte[1024];
                        // 接收数据报的包
                        DatagramPacket packet = new DatagramPacket(data, data.length);

                        // 获取socket引用，以便接下来进行数据监听
                        DatagramSocket localUDPSocket = LocalUDPSocketProvider.getInstance().getLocalUDPSocket();
                        if (localUDPSocket != null && !localUDPSocket.isClosed())
                        {
                                // ! 设置读超时时间，确保在MobileIMSDK的心跳超时到来时，下方的receive线束block状态，从而
                                //   让它所属的thread线程结束生命周期，防止网络长时间不好的情况下，能正常回收thread所占内存
                                //   防止因此而导致的OOM（注意：本超时建议不要短于MB框架的心跳超时时长，也不应太长否则不能即
                                //   时结束thread，超时时间只要长于心跳超时时间，就不会干扰正常的MobileIMSDK通信和心跳算法）。 - 20190326
                                localUDPSocket.setSoTimeout(KeepAliveDaemon.NETWORK_CONNECTION_TIME_OUT + KeepAliveDaemon.KEEP_ALIVE_INTERVAL);

                                // ! 做好异常捕获，让代码更健壮！ - 20190326
                                try{
                                        //接收数据
                                        localUDPSocket.receive(packet);

                                        // 通知处理者
                                        Message m = Message.obtain();
                                        m.obj = packet;
                                        messageHandler.sendMessage(m);
                                }
                                catch(Exception e){
                                        Log.d(TAG, "【IMCORE】【udpListeningImpl】localUDPSocket.receive()超时已到来" +
                                                        "，本socket句柄将被正常回收，socket监听线程也将正常结束生命周期。。。("+(thread == null ?"":thread.getId())+")");
                                        try{
                                                if(localUDPSocket != null) {
                                                        localUDPSocket.close();
                                                        localUDPSocket = null;
                                                }
                                        }catch(Exception ee){
                                                Log.d(TAG, "【IMCORE】【udpListeningImpl】IN localUDPSocket.close(), cause="+ee.getMessage());
                                        }
                                }
                        }
                }
        }

【3】将第2）步里我给你的代码，替换到你从Github上下载的源码中的这个方法（点击此下载此类的java源码），后你自已重新编译运行。

【4】运行观察，然后反馈难我结果，如果如预期的那样问题不再出现就表示问题解决，我就可以将改动的代码合并到正式版里。

引用：JackJiang 发表于 2019-03-26 12:49
APP能在前台长亮运行7、8个小时？你这不是普通用的用户场景吧。

是运行在专门的设备上的吗？

是的  运行在一个23寸的平板上的，相当于指挥平台的一个中心点，监控终端的

引用：秋草里黄 发表于 2019-03-26 14:55
是的  运行在一个23寸的平板上的，相当于指挥平台的一个中心点，监控终端的

按我3楼的回复做，确保运行的是我改过的代码，然后你再运行观察，并反馈给我！

引用：JackJiang 发表于 2019-03-26 14:58
按我3楼的回复做，确保运行的是我改过的代码，然后你再运行观察，并反馈给我！

问题已解决，没有出现oom，谢谢老哥！

引用：秋草里黄 发表于 2019-03-27 11:35
问题已解决，没有出现oom，谢谢老哥！

有个新问题了  客户端总是掉线，重连成功又掉线，不稳定

引用：秋草里黄 发表于 2019-03-27 13:11
有个新问题了  客户端总是掉线，重连成功又掉线，不稳定

你用我打的这个jar覆盖到你的工程里（记得把你之前自已改的代码的都删除掉！），然后继续观察！
注意：一定要把昨天我告诉你的，或者你自已改过的全部清空源，不然就全搞乱了。
mb-android.zip (41.8 KB , 下载次数: 2 , 售价: 1 金币)

6 年前 上传

请点击文件名下载附件！
售价: 1 金币  [记录]  [如何获取金钱？]

引用：秋草里黄 发表于 2019-03-27 11:35
问题已解决，没有出现oom，谢谢老哥！

不能这样改哦、改了之后oom不会出现了   但是总是掉线，客户端之间收不到消息。还原jar包后，就正常了，不过oom还是存在很大风险

引用：秋草里黄 发表于 2019-03-27 13:47
不能这样改哦、改了之后oom不会出现了   但是总是掉线，客户端之间收不到消息。还原jar包后，就正常了， ...

总是掉线应该是你的网络不良导致的，
你理性分析一下，看一下代码就能明白，之所发OOM，就是因为你的网络总是掉线，导致不断的尝试重新连接、新建trhead才导致的OOM（换名话说，改动之前和改动之后的代码，有一样肯定没有变化，就是你的网终环境，正是因为它才导致不断掉线和重试，否则如果如你所说不掉线，怎么可能还会OOM。能理解吧？）。

所以，我分析认为：
1）你的网络品质需要进行长测，看看实际情况，再针对这个情况来分析程序的表现；
2）我给你的jar理论上是肯定能解决OOM，而且它的改动也不存在会让它总是掉线，掉线的原因不是代码，而是你的网络本身存在不健康的原因。

所以，你看问题，要看的深一点，看到本质。

总之，我建议你下一步，就是用长测工具，评估网络品质：
1）手机端ping服务端工具，可以在这里下载：http://www.52im.net/thread-145-1-1.html
2）服务端ping手机的工具，可以在这里下载：http://www.52im.net/thread-610-1-1.html

你可以长测一个星期，并把双向测试的数据进行记录：延迟、丢包率、抖动等数据，每隔半小时或1小时做记录。

切记：网络能信程序不要评感觉，感觉没有任何帮助，只有数据才有说服力，才能帮助分析问题。