简体   繁体   English

内存泄漏线程

[英]Memory leaking thread

I have a TabHost with TextViews associated to each tab, in an Activity context. 我在Activity上下文中有一个TabHost,它具有与每个选项卡关联的TextViews。 Currently there's also an AsyncTask which manages the TCP socket and when it receives some kind of information, it's sent to the main Activity handler, who calls a method to append the text to the current TextView. 当前,还有一个用于管理TCP套接字的AsyncTask,当它接收到某种信息时,它将被发送到主Activity处理程序,该处理程序调用将文本附加到当前TextView的方法。

Well, after a while (approx 5 minutes) of running, I notice how it starts hanging and finally I get an ANR. 好吧,经过一会儿(大约5分钟),我注意到它是如何开始挂起的,最后我得到了ANR。 So I installed Memory Analyzer for Eclipse and in conjunction with DDMS, I was able to find out what seems to be the bottleneck, but not how to deal with it. 因此,我安装了适用于Eclipse的Memory Analyzer,并与DDMS结合使用,我能够找出似乎是瓶颈的地方,但无法找到解决方法。

Using the previously mentioned tools, I was able to see hundreds of lines like the ones on this pic: 使用前面提到的工具,我能够看到数百行,如这张图片上的行:

在此处输入图片说明

BTW : There's a strange detail in that pic, the Thread Id is always 1; 顺便说一句 :该图片中有一个奇怪的细节,线程ID始终为1; shouldn't it be different for each thread as the append is called on different threads? 每个线程都不同,因为在不同线程上调用了append吗?

Those hundreds of lines reference to the two 'appends' you may see in the code above. 数百行引用了您可能在上面的代码中看到的两个“追加”。 I'm new to the thread world, so if you see something weird, I'd appreciate any advice. 我是线程世界的新手,所以如果您看到一些奇怪的东西,我将不胜感激。 This is the code where the bottleneck is: 这是瓶颈所在的代码:

// tab = is the name of the tab where to append the new text
// line = the line to append; it may contain spans, colors, bold text, etc... that's why it's a SpannableStringBuilder
// ColorLine is a method that just returns a SpannableStringBuilder-formatted string

synchronized private static void Write2Tab(final String tab, final SpannableStringBuilder line) {
  final TabHost lth = (TabHost) activity.findViewById(android.R.id.tabhost);
  final TextView tabContent = (TextView) lth.getCurrentView();

  new Thread(new Runnable() {
    public void run() {
      String curtab = getCurrentTabName();

      // If the current tab is the one where we need to write, we do
      if (tab.equalsIgnoreCase(curtab)) {
        activity.runOnUiThread(new Runnable() {
          public void run() {
            tabContent.append(linea);
            tabContent.append((ColorLine("\n", Color.WHITE, false, 0, 1)));
          }
        });
      }
    }
  }).start();

  [...]
}

I've had 2 more memory leaks in my code that I was able to fix, but this one's starting to be a bit hard... Any ideas of why is this happening and how to fix it? 我的代码中有2个以上的内存泄漏可以修复,但是这开始有点困难...关于这种情况为什么发生以及如何解决的任何想法?

--------------- EDIT --------------- ---------------编辑---------------

After several days of frustrating research about leaks in my app, I found out there was more than one. 经过几天对应用程序泄漏的令人沮丧的研究,我发现其中不止一个。 I managed to solve them, the one I originally posted had to do with John Vint's post, there was an issue with the buffering control which made a substancial accumulation of SpannableStringBuilder objects in the TextView, so I'm accepting his post. 我设法解决了它们,我最初发布的内容与John Vint的帖子有关,缓冲控件存在问题,该控件在TextView中大量堆积了SpannableStringBuilder对象,所以我接受他的帖子。 Now I have a different issue with another curious leak but it has nothing to do with the original post so I'm going to open a new question. 现在,我有另一个奇怪的泄漏问题,但这与原始帖子无关,所以我要打开一个新问题。

How large does the StringBuilder become? StringBuilder会变成多大?

If the thread is stuck at 253 like it shows in your heap dumb all I can think of is that you are running out of heap space and are getting a GC overhead limit reached. 如果线程卡在253上,就像它在堆堆哑中显示的那样,那么我能想到的就是您用完了堆空间并达到了GC开销限制。

If that's the case you will need buffer the StringBuilder (ie if the length > N than remove the oldest line, where N is a large enough number to have history but small enough to prevent OOM). 如果是这种情况,您将需要缓冲StringBuilder(即,如果长度> N而不是删除最旧的行,则N是足够大的数字以具有历史记录,但又足够小以防止OOM)。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM