第17讲 | 一个线程两次调用start()方法会出现什么情况？

一课一练: 使用了两种方式获取当前程序的线程数。 1、使用线程管理器MXBean 2、直接通过线程组的activeCount 第二种需要注意不断向上找父线程组，否则只能获取当前线程组，结果是1 结论: 使用以上两种方式获取的线程总数都是5个。 main Attach Listener Signal Dispatcher Finalizer Reference Handler 此外，如果使用的IDE是IDEA 直接运行会多一个Monitor Ctrl-break线程，这个是IDE的原因。debug模式下不会有这个线程。

做了一个test分析老师的问题，观察到的情况如下： JVM 启动 Hello World的线程分析 环境： macOS + jdk8 检测获得 Thread[Reference Handler,10,system] Thread[Finalizer,8,system] Thread[main,5,main] Thread[Signal Dispatcher,9,system] Hello World! 其中： Reference Handler：处理引用对象本身的垃圾回收 Finalizer：处理用户的Finalizer方法 Signal Dispatcher：外部jvm命令的转发器 在jdk6环境中 还有一个Attach Listener的线程 是负责接收外部命令的，如jmap、jstack

theadlocal里面的值如果是线程池的线程里面设置的，当任务完成，线程归还线程池时，这个threadlocal里面的值是不是不会被回收？

“我们会发现一个特别的地方，通常幻象引用都会和引用队列配合清理机制使用，但是 ThreadLocal 是个例外，它并没有这么做。” 老师，Entry继承的是WeakReference，这个是弱引用吧。 main: System.out.println("hello world"); ThreadGroup group = Thread.currentThread().getThreadGroup(); ThreadGroup topGroup = group; while (group != null) { topGroup = group; group = group.getParent(); } int nowThreads = topGroup.activeCount(); Thread[] lstThreads = new Thread[nowThreads]; topGroup.enumerate(lstThreads); for (int i = 0; i < nowThreads; i++) { System.out.println("线程number：" + i + " = " + lstThreads[i].getName()); } out: 线程number：0 = Reference Handler // 计算对象是否可达？ 线程number：1 = Finalizer // 回收对象时触发的finalize方法？ 线程number：2 = Signal Dispatcher // 线程调度员 线程number：3 = main 线程number：4 = Monitor Ctrl-Break // 监控器，锁相关

1、站在应用程序方面，只创建了一个线程。 2、站在jvm方面，肯定还有gc等其余线程。 总结： 1、线程是系统调度的最小单元，应该是进程吧。线程是操作系统的资源，在运行的时候会打开文件描述符等。 2、 resume、stop、suspend等已经被废弃了 3、线程的等待和唤醒，建议使用reentrantlock的condition wait/notify方法 4、可以使用线程的join方法、countdownlatch、cyclicbarrier、future等进行线程的等待

现在觉得踩坑是一种很好学习方法

等待与阻塞有什么区别呢

老师，我有一点疑问，在线程池里复用线程时是不是对同一个线程调用了多次.start()方法呢？

杨老师请教你，关于高并发和线程池，我刚刚入门，工作中没有涉及过这一块。我阅读了oracle java tutorial high level concurrency 章节，阅读并粗略理解了《并发编程实践》这本书，想进一步清晰我的理解，我现在苦于在实践练习方面不知道怎么进行。老师有什么具体可行的思路指点一下吗？留言圈里有好多大神，在这里同时也请教其他的朋友。谢谢老师，谢谢大家。

通常弱引用都会和引用队列配合清理机制使用，但是 ThreadLocal 是个例外，它并没有这么做。 这意味着，废弃项目的回收依赖于显式地触发，否则就要等待线程结束，进而回收相应 ThreadLocalMap！这就是很多 OOM 的来源 这个平时还真没注意