Java中的线程池的负载平衡
免责声明：这与这个。
有些任务可以同时消耗网络和CPU。有时性能会粘在网络中，有时会粘在CPU中。因此，根据我需要在程序运行之前无法精确设置的不同线程号。理想情况下，每个任务都应记录其时间（以及其他一些参数），如果时间增加 - ＆gt;当任务更快地完成时，线程池会减小线程 - ＆gt;线程的数量应增加。
当然，应该有防止连续负载平衡的保护：例如，当系统添加1个线程并将其删除时，然后一次又一次地重复此操作，因为任务时间会发生变化。
Java提供与此类似的东西吗？
Disclaimer: this is not the same as this one.
There are some tasks that can consume both network and CPU. Sometimes performance sticks into a network, sometimes into the CPU. So depending on that I need different thread number that can not be precisely set before a program run. Ideally, each task should log its time (and some other parameters) and if time increases -> thread pool decreases threads otherwise when a task is completed faster -> number of threads should be increasing.
Of course, there should be protection from continuous load balancing: e.g. when the system adds 1 thread and remove it, then repeat this again and again because task time changes.
Does java offer something similar to this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
目前在Java，线程非常昂贵，直接映射到主机OS线程一对一。它们会影响内存使用量和CPU使用情况。因此，我们通常将线程数限制为少数几个，通常大约是核心的数量。因此，如今，增加/减小线程池的大小不太可能是有意义的。
project loom中的虚拟线程
听起来您的场景是 firtual threads （ fibers ）来自 project loom project。许多虚拟线程映射到单个主机OS线程。
在今天的Java线程中，如果Java代码块，则主机OS线程块。该线程没有进一步的工作。使用虚拟线程，当Java代码阻止其分配的主机OS线程并“停放”时，虚拟线程被卸下。当该代码最终返回，因此需要进一步执行时，将其安装到另一个主机OS线程上。与主机OS线程的阻止/解密相比，虚拟线的停车和安装速度要快得多。虚拟线程对内存和CPU的影响要小得多。因此，我们可以在常规硬件上同时运行数千甚至数百万的线程。
在您的工作负载可能上升或下降的情况下，Project Loom中的虚拟线程设施将自动管理线程池和调度。您应该看到大大改善的吞吐量，而无需付出任何努力。
一些警告：
虚拟线程和其他项目织机功能可作为Java 19中的预览功能可用，现已提供实验性构建。
有关更多信息，请参阅项目织机团队（例如Ron Pressler和Alan Bateman）的文章，演讲和访谈。
Currently in Java, threads are quite expensive, being mapped directly one-to-one to host OS threads. They impact both memory usage and CPU usage. So we usually limit the number of threads to a few, often roughly the number of cores or so. So increasing/decreasing the size of the thread pool is not likely to make sense nowadays.
Virtual threads in Project Loom
Sounds like your scenario is ideal for the virtual threads (fibers) coming from the Project Loom project. Many virtual threads are mapped to a single host OS thread.
In today's Java threading, if the Java code blocks, the host OS thread blocks. No further work is performed on that thread. With virtual threads, when the Java code blocks the virtual thread is dismounted from its assigned host OS thread, and “parked”. When that code eventually returns, and therefore needs further execution, it is mounted onto another host OS thread. This parking and mounting of virtual threads is much faster than blocking/unblocking of host OS threads. Virtual threads have much less impact on memory and and CPU. So we can have thousands, or even millions, of threads running simultaneously on conventional hardware.
In your scenario where your work load may go up or down, the virtual thread facility in Project Loom will automatically manage the thread pool and scheduling. You should see vastly improved throughput with no effort on your part.
A few caveats:
Virtual threads and other Project Loom features are available as preview features in Java 19, with experimental builds available now.
For more information, see the articles, presentations, and interviews by members of the Project Loom team such as Ron Pressler and Alan Bateman.