jimrok

@cheng6563 线程池的作用还是为了减少创建线程的开销，在 linux 下是存在用户态和核心态的指令差别的，核心态运行在 cpu 0 的指令级别上，是一种高优先级的程序指令，通常叫系统调用，这些指令能干很危险的操作，例如对物理内存的访问。而用户态只能看到虚拟内存了，这就倒是创建线程时候，会在两个状态的代码之间来回切换。当你做高并发的应用时，例如 1000req/s 的操作时，你就不能忽视这种开销了。你可以做个实验，当你创建 100 万个 thread 对象，即便都在线程池中什么任务都不干，机器已经卡的不行了。

Java 的这个线程池设计问题可以追朔到 java 语言创立之初的作用，最早 java 是想提供给智能硬件编程用的，没有考虑服务器大并发的使用场景，后续的 golang 还有 erlang 的并发模型都和 java 不一样，只能说 java 用在服务器上编程大大超出了创建者的预期。每年都有新的技术出现，开发者可能疲于追求新的技术，而忘记了探讨一项技术的本源是什么，上面太多的回答是从使用的角度解释的，可能从业这么长时间，也没有去了解过这些技术是怎么演进的。我想，可能参与这个过程的老师傅们已经下岗了。

首先你的说法是没有问题的，这个问题是 java 的问题，如果你学习过其他语言，如 erlang ，它是可以马上创建新的线程去执行的。erlang 可以轻松并发几百万个线程。其实 erlang 这个不叫线程，叫协程。java 做不到是因为线程太昂贵了，这个资源创建时候，需要准备部分线程栈存放线程的元数据，大概要消耗一小部分内存，同时要映射到操作系统的线程上，如果经常这样做，开销是非常高的，可能会超过你执行线程的任务。所以，现在 java 的模式是做一个线程池，通过一个队列来接受任务，避免反复创建线程的开销。

可以不放，但是 mqtt 的服务你的做调整吧，如果 mqtt 是自己定制的，可以做。因为每个 client 有自己的 session ，如果你能用 payload 的 id 关联到 sessionid 上，那就可以让 mqtt 给特定 session 的设备推消息。

小学那点知识，家长都可以辅导，没啥好坏之分，小学就是培养学习习惯吧，主要是能完成作业。

煤炭基本是不会新增产能了，维持现有产能，基本国内煤炭要比外煤贵，但未来外贸减少，人民币贬值，外煤可能就不便宜，还得用内煤，看看几个煤炭上市公司回报都不错，未来应该也是这样。

3 以为是退路，其实 3 基本没戏了。经济下行，公务员已经无法供养那么多了。

存在风险的系统，供应商有风险的该替换的替换，反正这个阶段别想怎么搞造轮子，吹概念，就需要性能提高 10%，费用减少 50%。

这个阶段不是应该先想着怎么来减少 IT 支出吗？没有必要的系统该关的关闭，没法维护的该退出退出，服务器能压缩的压缩，能自动化的自动化，减少人为操作。