线程run（）函数中的Android内存泄漏

我有一个从服务运行的线程。跑步的循环在15分钟内没有任何问题。在那之后-我的GC因为内存泄漏而变得疯狂，然后这个函数就不能正常工作了

我使用DDMS分配跟踪器来查找泄漏，似乎泄漏在

input=in.readLine（）中行。我真的不知道如何解决它，但这是我的代码、堆栈跟踪和分配跟踪器快照：

代码：

@Override
public void run() {
    startKeepAliveTimer();  
    try {
            socket = new Socket(host, port);
            if (socket != null)
            {
                Log.i("ServerConnection", "Server connection opened");
                this.app.setConnectedToServer(true);
                serverManager.loginToServer();
            }
            else
                app.setConnectedToServer(false);                
            InputStreamReader inputStreamReader = new InputStreamReader(socket.getInputStream());
            BufferedReader in = new BufferedReader(inputStreamReader);
            String input;
            while (app.isConnectedToServer()) 
            {
                app.getFacebookManager().refreshAccessToken();                                      
                input = in.readLine();
                if (input != null)
                {
                    lastOnline = System.currentTimeMillis();
                    input = input.trim();
                    input = app.decrypt(input);
                    Log.e("Server Reponse", input);                 
                    serverManager.processData(app.convertToJSONObject(input));
                }
            }
        } catch (IOException e) {
            Log.e("ServerConnection", e.toString());
        }           

        Log.i("ServerConnection", "Server connection closed");
}



private void startKeepAliveTimer() {
    Timer timer = new Timer("keepAlive", true);
    timer.scheduleAtFixedRate(new TimerTask() {         
        @Override
        public void run() {
            keepAlive();                
        }
    }, 0, keepAlive);
}

stacktrace

11-12 09:55:38.349: D/dalvikvm(2251): GC_CONCURRENT freed 1164K, 23% free 9987K/12871K, paused 1ms+1ms
11-12 09:55:38.899: D/dalvikvm(2251): GC_CONCURRENT freed 1072K, 23% free 9989K/12871K, paused 1ms+1ms
11-12 09:55:39.439: D/dalvikvm(2251): GC_CONCURRENT freed 1075K, 23% free 9967K/12871K, paused 0ms+1ms
11-12 09:55:39.959: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 0ms+1ms
11-12 09:55:40.499: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9992K/12871K, paused 0ms+0ms
11-12 09:55:41.069: D/dalvikvm(2251): GC_CONCURRENT freed 1079K, 23% free 9983K/12871K, paused 1ms+1ms
11-12 09:55:41.749: D/dalvikvm(2251): GC_CONCURRENT freed 1094K, 23% free 9967K/12871K, paused 2ms+2ms
11-12 09:55:42.379: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:42.909: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:43.459: D/dalvikvm(2251): GC_CONCURRENT freed 1061K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:43.979: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:44.549: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:45.079: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:45.629: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:46.179: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:46.709: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:47.229: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:47.749: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:48.299: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:48.839: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9989K/12871K, paused 1ms+0ms
11-12 09:55:49.379: D/dalvikvm(2251): GC_CONCURRENT freed 1075K, 23% free 9991K/12871K, paused 1ms+0ms
11-12 09:55:49.909: D/dalvikvm(2251): GC_CONCURRENT freed 1078K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:50.429: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 3ms+1ms
11-12 09:55:50.949: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:51.499: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:52.019: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 0ms+0ms
11-12 09:55:52.539: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+1ms
11-12 09:55:53.069: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 2ms+1ms
11-12 09:55:53.609: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 1ms+0ms
11-12 09:55:54.139: D/dalvikvm(2251): GC_CONCURRENT freed 1045K, 23% free 9967K/12871K, paused 0ms+1ms

分配跟踪程序：
您从不在套接字实例上调用close。也许这个问题是相关的，但我不想结束它。。。它是到我的服务器的持久连接。。只有当我有一个错误时我才会关闭。可能字符串效率不高，并且在
input=input.trim（）中获得了大量“脏”内存和
input=app.decrypt（输入）。尝试使用
in.read（char[]cbuf，int off，int len）
并预先分配一个char[]，然后解密char[]中的数据，这可能会有所帮助。那么，为什么input=in.readLine（）在结束时没有收集到数据（正如你在跟踪器中看到的那样）？@AsafNevo听起来像是在使用螺丝刀，而你需要使用锤子。。。