垃圾收集器是一个后台线程（daemon thread）吗？
谢谢。
垃圾收集器是守护线程吗？
12
- bunty
7
我认为它必须作为本地线程实现。 - Suraj Chandran
@sean...谢谢你的纠正... - bunty
1@Suraj Chandran：不需要将垃圾收集器放在单独的线程中。实际上，这样做相当复杂（尽管它具有一些优点，例如像正常的“停止-世界”收集器那样不会中断程序）。 - DarkDust
@DarkDust，实际上现在GC和JIT都在后台高优先级线程中运行。在后台线程中运行GC有太多的好处可以利用。 - bestsss
1@DarkDust，实际上大多数现代JVM都会受益于并发GC，前提是系统有空闲核心。简单来说：如果没有并发GC，就无法正确地管理大堆，暂停时间将变得难以忍受。 - bestsss
显示剩余2条评论
5个回答
7
我认为垃圾回收线程是一个守护线程。守护线程是低优先级的线程，间断地在后台运行执行垃圾回收操作或其他Java运行时系统的请求。
- Buhake Sindi
4
5《Java并发编程实战》一书中的原文如下："当JVM启动时，它创建的所有线程（例如垃圾回收器和其他清理线程）都是守护线程，除了主线程。"。我对其进行的翻译如下：JVM启动时创建的所有线程（包括垃圾回收器和其他清理线程）都是守护线程，除了主线程。 - John
5一个守护线程仅是一个不强制 JVM 持续运行的线程。也就是说，有两种类型的线程：非守护线程和守护线程。非守护线程执行重要的工作，而守护线程执行后勤任务。当所有非守护线程都运行结束时，JVM 会自动关闭并杀死所有守护线程。这就是你创建守护线程时想要的结果吧？只是一些旨在支持非守护线程的后勤任务。 - Ken Bloom
1如果垃圾回收器是一个守护线程，并且可能在所有非守护线程完成运行时被终止，那么这是否意味着所有引用可能尚未被垃圾回收并且仍可能占用内存？ - ion20
1@ion20 当JVM关闭时，它会释放它曾经占用的所有内存。不再存在任何引用。因此，没有... - xeruf
2
至少从 java.lang.Thread 的角度来看，这不是一个线程。
- adarshr
2
什么意思是它不是来自java.lang.Thread？用户空间多任务还是本地实现。 - Dead Programmer
我的意思是，这不是一个像其他普通线程（包括守护线程）一样可以在Java中看到和管理的线程，后者只是
java.lang.Thread类的实例。因此，我间接地暗示它是一个从用户层面抽象出来的本地实现。 - adarshr0
是的：http://www.javaperspective.com/daemon-threads.html： 守护线程被认为是在后台运行的线程，通常用作用户线程的服务提供者。例如，Java垃圾收集器就是一个守护线程。
- TT_ stands with Russia
0
在JDK 1.8中，以下线程列出如下：
ThreadMXBean mxbean = ManagementFactory.getThreadMXBean();
for(long id:mxbean.getAllThreadIds())
System.out.println(mxbean.getThreadInfo(id));
输出 -
- "Attach Listener" Id=5 可运行
- "Signal Dispatcher" Id=4 可运行
- "Finalizer" Id=3 等待 java.lang.ref.ReferenceQueue$Lock@63947c6b
- "Reference Handler" Id=2 等待 java.lang.ref.Reference$Lock@2b193f2d
- "main" Id=1 可运行
没有GC线程。可以安全地说垃圾回收过程是本地的。
- bina ramani
-3
守护线程是一种即使在JVM退出后仍然继续运行的线程。引自Oracle文档。 当Java虚拟机启动时，通常有一个单个非守护线程（通常调用某个指定类的main方法）。Java虚拟机会继续执行线程，直到发生以下情况之一： •Runtime类的exit方法已被调用，并且安全管理器已允许执行退出操作。 •所有非守护线程都已死亡，或者通过从run方法返回或抛出超出run方法的异常来结束。
因此，如果GC是守护线程，则它应该是由Java运行时生成的本机线程，但可以在JVM退出后继续运行。
- srajan
1
2“守护线程也是一种线程，即使JVM退出后仍然继续运行。” 不，JVM退出后不能有Java线程。 - xeruf
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接