【问题标题】:Memory consumed by a thread线程消耗的内存
【发布时间】:2014-09-21 21:30:44
【问题描述】:

我需要监控我的应用程序产生的线程消耗的内存量。这个想法是在贪婪线程消耗过多内存时采取纠正措施。我提到了How much memory does my java thread take?。该链接上的建议之一是在ThreadMXBean.中使用getThreadAllocatedBytes,我用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();
            }
        }

我在四个线程上运行该作业相当长的时间。虽然作业不会连续积累内存,但getThreadAllocatedBytes返回的值一直在增加,一次也没有下降。这意味着getThreadAllocatedBytes 不会返回线程使用的堆上的实际内存量。它返回自线程启动以来在堆上分配的内存总量。我的平台详情如下:

Linux PG85213.egi.ericsson.com 3.5.0-030500-generic #201207211835 SMP Sat Jul 21 22:35:55 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux java版本“1.7.0_45”
Java(TM) SE 运行时环境 (build 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();
}
}

【问题讨论】:

  • 请注意,System.gc() 确实保证 GC 运行。特别是在您的情况下,System.gc() 可能以亚毫秒间隔调用,VM 可能会决定将 GC 运行推迟到某个任意时间;通常到当可用内存在某种程度上变低时。
  • 您能否提供一个更完整的示例,我想在本地重复您的实验。
  • SAP JVM (tools.hana.ondemand.com/#cloud) 似乎完全支持此功能。不过,我从来没有使用过这个虚拟机,只知道它是受支持的。

标签: java multithreading memory memory-management


【解决方案1】:

据我所知,在运行时没有可靠的方法来执行此操作。正如source question 中所指出的,堆是共享资源,因此单个线程的堆大小没有意义,因为它会与来自其他线程的对象引用重叠。

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

我知道人们使用Java Agents to instrument the allocation of objects,然后使用弱引用来监控它何时被GC'd。但是,这样做对性能的影响很大。非常高。

您最好在运行时使用启发式算法和unit testing to ensure that memory stays within bounds。例如,您可以使用 JMX 来监控堆大小,当您看到老一代增长时,您可以发出警报。使用 getThreadAllocatedBytes 计算分配率也很有用。

良好的运行时监控工具:appdynamicsnewrelicvisualvmyourkit

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

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

【讨论】:

  • 我主要对应用程序上下文中的运行时监控感兴趣。因此,在我们的案例中,从外部分析应用程序不会有太大帮助。但是,我想检查分析器是否提供了每个线程的堆内存消耗。除了 visualVM 之外的所有设备都获得了商业许可。所以我只检查了 VisualVM。它没有给出每个线程使用的堆内存量。我不确定是否有任何其他分析器提供此功能。根据到目前为止所做的回复和所有搜索,似乎没有办法获得每个线程消耗的堆内存量。
  • @SarveswaranMeenakshiSundaram 是正确的,没有既定的方法可以做到这一点。正如一些回复所指出的那样,“每个线程消耗的堆内存”实际上是什么意思。堆是共享资源,任何单个对象都可以被多个线程访问。这就是为什么我提到“保留”大小,这是一个可以离线或在运行时计算的指标。但是在运行时它会花费,并且取决于你如何做它也不准确。离线是执行此操作的正常方式,MAT 等免费工具支持这一点。两者的详细信息都在上面。
【解决方案2】:

Java VisualVM 可用于“监视本地应用程序并查看有关内存堆、线程活动和 Java 虚拟机 (JVM) 中加载的类的实时高级数据。监视应用程序强加于开销低,可长时间使用。”

另见How to monitor Java memory usage? 其他可能性。

【讨论】:

  • 我试过 VisualVM。有一列显示每个线程分配的内存量。这与 ThreadMXBean 中的 getThreadAllocatedBytes 返回的值相匹配。即使是可视虚拟机也不会给出每个线程使用的堆上的实际内存!这意味着没有 JVM 级别的支持/hack 来实时监控每个线程使用的内存量。
  • @gumuruh 不知道。这个问题与Netbeans无关。
猜你喜欢
  • 2015-10-06
  • 2016-04-29
  • 2017-05-28
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-06-14
相关资源
最近更新 更多