线程占用的内存

Sar*_*ram 12 java memory multithreading memory-management

我需要监视由我的应用程序生成的线程消耗的内存量.如果贪婪的线程消耗太多内存,那么我们的想法是采取纠正措施.我已经提到我的java线程需要多少内存?.关于该链接的建议之一是getThreadAllocatedBytesThreadMXBean.我尝试使用getThreadAllocatedBytes以下工作时使用.

List<Long> primes = new ArrayList<Long>();
long i = 0;
while (true) {
            primes.add(++i);
            if ((i % 10) == 0) {
                primes.clear();
                System.runFinalization();
                System.gc();
            }
        }
Run Code Online (Sandbox Code Playgroud)

我花了很长时间在四个线程上运行这个工作.虽然作业不会持续累积内存,但返回的值getThreadAllocatedBytes会不断增加,甚至不会下降一次.这意味着getThreadAllocatedBytes不会返回线程使用的堆上的实际内存量.它返回自启动以来线程在堆上分配的内存总量.我的平台详细信息如下:

Linux的PG85213.egi.ericsson.com 3.5.0-030500泛型#201207211835 SMP周六7月21日22时35分55秒UTC 2012 x86_64的x86_64的x86_64的GNU/Linux的Java版本"1.7.0_45"
的Java(TM)SE运行时环境(建1.7.0_45-b18)Java HotSpot(TM)64位服务器VM(内置24.45-b08,混合模式)

上述行为是否符合预期的行为getThreadAllocatedBytes?如果是这样,是否无法在线程使用的堆上找到有效内存.

我列出了完整的程序供参考:

package workbench;

import java.lang.management.ManagementFactory;
import com.sun.management.ThreadMXBean;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.Executors;
import java.util.logging.Level;
import java.util.logging.Logger;

public class AnotherWorkBench {

private static final CountDownLatch latch = new CountDownLatch(4);
static final List<Long> threadIds = Collections.synchronizedList(new ArrayList<Long>());

private void dummyJob() {
    List<Long> primes = new ArrayList<Long>();
    long i = 0;
    while (true) {
        primes.add(++i);
        if ((i % 10) == 0) {
            primes.clear();
            //introduce sleep to prevent process hogging 
            try {
                Thread.currentThread().sleep(2000);
            } catch (InterruptedException ex) {
                Logger.getLogger(AnotherWorkBench.class.getName()).log(Level.SEVERE, null, ex);
            }
            System.runFinalization();
            System.gc();
        }
    }
}

private void runDummyJobs() {

    Runnable dummyJob = new Runnable() {
        @Override
        public void run() {
            threadIds.add(Thread.currentThread().getId());
            latch.countDown();
            dummyJob();
        }
    };

    Runnable memoryMonitorJob = new Runnable() {
        @Override
        public void run() {

            System.out.println(Thread.currentThread().getName() + " : Monitor thread started");
            ThreadMXBean threadMxBean = (ThreadMXBean) ManagementFactory.getThreadMXBean();
            threadMxBean.setThreadAllocatedMemoryEnabled(true);

            while (true) {
                for (Long threadId : threadIds) {
                    System.out.println(Thread.currentThread().getName() + " : Thread ID : " + threadId + " : memory = " + threadMxBean.getThreadAllocatedBytes(threadId) + " bytes");
                }

                //wait between subsequent scans
                try {
                    System.out.println(Thread.currentThread().getName() + " : secondary sleep");
                    Thread.currentThread().sleep(5000);
                    System.out.println(Thread.currentThread().getName() + " : out of secondary sleep");
                } catch (InterruptedException ex) {
                    Logger.getLogger(WorkBench.class.getName()).log(Level.SEVERE, null, ex);
                }
            }


        }
    };

    Executors.newSingleThreadExecutor().submit(dummyJob);
    Executors.newSingleThreadExecutor().submit(dummyJob);
    Executors.newSingleThreadExecutor().submit(dummyJob);
    Executors.newSingleThreadExecutor().submit(dummyJob);

    try {
        latch.await();
    } catch (InterruptedException ex) {
        Logger.getLogger(AnotherWorkBench.class.getName()).log(Level.SEVERE, null, ex);
    }
    Executors.newSingleThreadExecutor().submit(memoryMonitorJob);
}

/**
 * @param args the command line arguments
 */
public static void main(String[] args) {
    new AnotherWorkBench().runDummyJobs();
}
}
Run Code Online (Sandbox Code Playgroud)

Chr*_*s K 9

据我所知,没有可靠的方法在运行时执行此操作.正如源代码问题所指出的那样,堆是一个共享资源,因此单个线程的堆大小没有意义,因为它将与来自其他线程的对象引用重叠.

也就是说,当我想知道单个线程的"保留"大小时,是保留大小是与您要求的大小不同但相似的度量,那么我通过进行堆转储然后使用MAT来实现(http://www.eclipse.org/mat/).

我知道人们使用Java代理来检测对象的分配,然后使用弱引用来监视它何时获得GC.然而,这样做对性能的影响很大.很高.

您可能最好在运行时使用启发式和单元测试,以确保内存保持在边界内.例如,您可以使用JMX监视堆大小,当您看到旧的gen增长时,您可以发出警报.使用getThreadAllocatedBytes来计算分配率也很有用.

良好的运行时间监控工具: appdynamics,NewRelic的,VisualVM的yourkit

对于离线内存分析,matjclarity非常好.

一个非常有用的工具可以帮助确定是否存在泄漏,或者至少与预期不同,是打印堆中当前每个类的实例数量的计数: jcmd <pid> GC.class_histogram.