如何处理内存泄漏而连续插入一个链表?如何处理、链表、内存

2023-09-05 05:21:46 作者:胸膛

我具有以下功能是从被连续运行的线程的运行()连续地调用。

I have following function which is called continuously from run() of a Thread which is continuously running.

private LinkedList<short[]> playerData = new LinkedList<short[]>();

public synchronized void setPlayerData(short[] buffer) {
        // Log.i(LOG_TAG, "Inside setData..");
        playerData.addLast(buffer);
        if (playerData.size() > 10) {
            // Log.i(LOG_TAG, "playerData not empty");
            playerData.removeFirst();
        }
    }

现在DDMS的分配跟踪说,很多对象都是内部addLast()(其实里面addLastImpl()),所以,我想明确地删除阵列,使他们的创造总是足够的内存堆。现在,

Now allocation Tracker of DDMS says that a lot of objects are created inside addLast() (actually inside addLastImpl() ), So for that I would like to delete the arrays explicitly so that their is always enough memory in Heap. Now,

在System.gc()的选项将不会帮助,因为它会同时在每次调用setPlayerData()被调用。 GC_CONCURRENT是吃所有的CPU周期,因为应用程序是时间非常敏感,甚至几毫秒的延迟是不能接受的。

有关LogCat中的信息请参见link,这是我的另外一个问题解决整个synarion。在这个线程我只是想用它除以一系列小问题来解决这个更大的问题。

For LogCat information please see the link, which is my another question addressing the whole synarion. In this thread I am just trying to solve that bigger problem by dividing it in set of small problems.

可能的解决方案:一种可能的解决方案可能是通过删除不需要的阵列,以释放内存空间显式。但在Java中怎样才能释放由运营商创造了一个数组?即

A possible solution A possible solution could be to free the memory space explicity by deleting the arrays which are not required. But in Java how can we free an array created by the new operator ? i.e.

short[] buffer = new short[320];
// do some operation on buffer
/// now how can I explicitly free memory by deleting the buffer, when its job is over..

我知道有垃圾回收利用所有这些事情的照顾。但是,在我的应用程序的 GC_CONCURRENT 吃掉了所有的时间。其他的进程,由于该饿死。这本来是巨大的,如果我能够明确地释放内存,即删除C ++。你可以在这里看到LogCat中的信息... A关于我的问题的详细问题

I know there is garbage collection to take care of all such things. But in my app GC_CONCURRENT eats up all the time. Other processes are starved due to this. It would have been great if I am able to explicitly free memory, i.e. delete in C++. You can see the LogCat information here...A detailed question regarding my problem

编辑2 3.指定数组为null

EDIT 2 3. Assign arrays to null

如何,这将有助于?空阵列将被安排,我想避免,因为该方法是从一个线程连续调用(每20毫秒)垃圾收集。如果我指定数组为null,GC_FOR_MALLOC消息将填补LogCat中...

How that will help ? null arrays will be scheduled to Garbage Collection which I want to avoid since the method is called from a thread continuously (in every 20 ms). If I assign the array to null, GC_FOR_MALLOC messages will fill the LogCat...

推荐答案

您的问题将不会被明确删除对象解决...基本上,因为没有办法做到这一点在Java中。

Your problem won't be solved by explicitly deleting objects ... basically because there is no way to do that in Java.

如果你的真正的为CMS收集器,以应对产生过多的垃圾,那么唯一的解决办法是使用一个对象池回收的缓存对象,而不是丢弃他们在地板上的GC来处理。但是,你必须要小心,你不跟别人替换当前的问题:

If you are really creating too much garbage for the CMS collector to cope with, then the only solution is to use an object pool to recycle the buffer objects instead of dropping them on the floor for the GC to deal with. However, you need to be careful that you don't replace your current problem with others:

再循环对象可能需要被清洗(零)。 在设计不当的对象池可以是内存泄漏。 在设计不当的对象池可以是并发的瓶颈。 在设计不当的对象池可以增加GC开销,特别是如果你有一个堆太小运行。

在另一方面,你真正的问题可能是你的堆是太小了,您要运行该应用程序。如果运行得接近极限,GC将不会在每次回收的垃圾。自运行GC的成本成比例的非垃圾的量,很容易地看到,GC的效率是非线性作为堆越接近满

On the other hand, your real problem may be that your heap is too small for the application you are trying to run. If you run too close to the limit, the GC won't reclaim much garbage each time. Since the cost of running the GC is proportional to the amount of NON-garbage, it is easy to see that the GC's efficiency is non-linear as the heap gets closer to full.