WorkManager 和高工作负载

发布于 2024-09-12 00:00:05 字数 246 浏览 3 评论 0原文

我正在开发一个与网络上数百个设备交互的应用程序。所提交的工作类型需要大量并发线程(主要是因为每个线程都需要网络交互并且单独执行,但也有其他原因)。目前,我们需要每个设备有大约 20-30 个线程进行交互。

简单计算一下,这就是数千个线程,甚至高达 10,000 个线程。如果我们抛开线程切换等方面的 CPU 损失,在 CentOS 64 位上运行的 Java 5 可以处理多少个线程?这只是 RAM 的问题还是还有其他我们应该考虑的问题?

谢谢!

I'm working on an application which interacts with hundreds of devices across a network. The type of work being committed requires a lot of the concurrent threads (mostly because each of them requires network interaction and does so separately, but for other reasons as well). At the moment, we're in the area of requiring about 20-30 threads per device being interacted with.

A simple calculation puts this at thousands of threads, even up to 10,000 threads. If we put aside the CPU penalty for thread-switching, etc., how many threads can Java 5 running on CentOS 64-bit handle? Is this just a matter of RAM or is there anything else we should consider?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

还如梦归 2024-09-19 00:00:05

在这种情况下,始终建议使用线程池。

线程池解决了两个不同的问题:由于减少了每个任务的调用开销,它们通常在执行大量异步任务时提供改进的性能,并且它们提供了一种限制和管理资源的方法,包括执行一组异步任务时消耗的线程。任务。每个ThreadPoolExecutor还维护一些基本统计数据,例如已完成任务的数量。

ThreadPoolExecutor 是您应该使用的类。

http://www.javamex.com/tutorials/threads/ThreadPoolExecutor.shtml

In such situation its always recomended to use Thread Pooling.

Thread pools address two different problems: they usually provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the resources, including threads, consumed when executing a collection of tasks. Each ThreadPoolExecutor also maintains some basic statistics, such as the number of completed tasks.

ThreadPoolExecutor is class you should be using.

http://www.javamex.com/tutorials/threads/ThreadPoolExecutor.shtml

绅刃 2024-09-19 00:00:05

我认为 java 最多 65k 个线程就可以了,你唯一需要考虑的是堆栈空间 - Linux 默认情况下为每个线程/进程分配 48k 作为堆栈空间,这对于 java 来说是浪费(它没有堆栈分配的对象) ,因此使用更少的堆栈空间)。这将轻松地将 500 兆用于 10k 线程。

I think up to 65k threads is OK with java, the only thing you need to consider is stack space - linux by default allocates 48k per thread/process as stack space, which is wasteful for java (which doesn't have stack-allocated objects, hence uses much less stack space). This will easily use 500 megs for 10k threads.

大海や 2024-09-19 00:00:05

如果这确实是一个绝对的要求,那么您可能不想查看专门为处理这种级别的并发线程而构建的语言,例如 erlang。

If this is really an absolute requirement, you might wan't to have a look at a language that's specifically build to deal with this level of concurrent threads, such as erlang.

寄居人 2024-09-19 00:00:05

就像其他人建议的那样,您应该使用 NIO。我们有一个应用程序使用了大量(但比您计划的要少得多)线程(例如 1,000 ),并且效率已经非常低了。如果您必须使用那么多线程,那么绝对是时候考虑使用 NIO 了。

对于网络,如果您的应用程序使用 HTTP,一个非常简单的工具是 Async-HTTP-client< /a> 由该领域两位非常著名的作者撰写。

如果您使用不同的协议,建议使用 Async-HTTP-client (netty) 的底层实现。

Like others are suggesting, you should use NIO. We had an app that used a lot (but much less than you are planning) of threads (e.g. 1,000 ) and it was already very inefficient. If you have to use THAT much threads, it's definitely time to consider the use of NIO.

For network, if your apps are using HTTP, one very easy tool would be Async-HTTP-client by 2 very famous author in this field.

If you use a different protocol, using the underlying implementation of Async-HTTP-client (netty) would be recommendable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文