Java线程性能
我正在开发一个 BitTorrent 客户端。 在与同行交流时，我与他们交流的最简单方法是为每个人生成一个新线程。 但是，如果用户想要与大量对等点保持连接，那么我会产生很多线程。
我想到的另一种解决方案是使用一个线程来迭代对等对象并运行它们 e 周期。
我检查了其他库，主要是用 ruby 编写的（我的是用 java 编写的），它们为每个新对等点生成一个线程。 您认为如果用户将连接数设置为 100 或 200 这样的高数字，生成一个线程会降低性能吗？
I am working on a bittorrent client. While communicating with the peers the easiest way for me to communicate with them is to spawn a new thread for each one of them. But if the user wants to keep connections with large number of peers that my cause me to spawn a lot of threads.
Another solution i thought of is have one thread to iterate through peer objects and run them for e period.
I checked other libraries mostly in ruby( mine is in java ) and they spawn one thread for each new peer. Do you think spawning one thread will degrade performence if user sets the number of connections to a high number like 100 or 200?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
除非您运行数千个线程，否则这应该不是问题。 我会考虑使用线程池进行折衷。 您可以在运行时检测 CPU 的数量，并根据该数量决定启动多少个线程，然后将工作分配给线程池。
It shouldn't be a problem unless you're running thousands of threads. I'd look into a compromise, using a threadpool. You can detect the number of CPUs at runtime and decide how many threads to spin up based on that, and then hand out work to the threadpool as it comes along.
您可以通过使用 非阻塞 IO (java.nio.* ）。
You can avoid the problem altogether by using Non-blocking IO (java.nio.*).
我建议使用 Executor 来保持线程数量。
有了这个，您基本上可以将“任务”添加到池中，一旦线程可用，它们就会完成。 这样，您就不会耗尽最终用户计算机的所有线程，同时仍然可以完成大量工作。 如果您将其设置为 16 之类的，那么您会非常安全，但您始终可以允许用户根据需要更改此数字。
I'd recommend using an Executor to keep the number of threads pooled.
With this, you can basically add "tasks" to the pool and they will complete as soon as threads become available. This way, you're not exhausting all of the enduser's computer's threads and still getting a lot done at the same time. If you set it to like 16, you'd be pretty safe, though you could always allow the user to change this number if they wanted to.
不......
一旦我有同样的疑问并创建了一个.net应用程序（4年前）有400个线程......
只要他们不做很多工作，用一台像样的机器你应该没问题...
No.....
Once I had this very same doubt and created a .net app (4 years ago) with 400 threads....
Provided they don't do a lot of work, with a decent machine you should be fine...
对于大多数工作站级计算机来说，几百个线程不是问题，并且编码更简单。
但是，如果您有兴趣追求自己的想法，可以使用 Java NIO 包提供的非阻塞 IO 功能。 Jean-Francois Arcand 的博客包含很多很好的提示从为 Glassfish 创建 Grizzly 连接器中学到的知识。
A few hundred threads is not a problem for most workstation-class machines, and is simpler to code.
However, if you are interested in pursuing your idea, you can use the non-blocking IO features provided by Java's NIO packages. Jean-Francois Arcand's blog contains a lot of good tips learned from creating the Grizzly connector for Glassfish.
例如，在 32 位 Windows 中，您实际上可以创建最大数量的本机线程（2 Gigs /（线程数 * ThreadStackSize（默认为 2MB））或类似的值）。 因此，如果连接过多，您可能会耗尽虚拟内存地址空间。
我认为折衷方案可能会起作用：使用一个线程池，例如运行 10 个线程（取决于机器）并均匀分配连接。 在线程内部循环分配给该线程的对等点。 并限制最大连接数。
Well in 32bit Windows for example there is actually a maximum number of native Threads you can create (2 Gigs / (number of Threads * ThreadStackSize (default is 2MB)) or something like that). So with too many connections you simply might run out of Virtual Memory address space.
I think a compromise might work: Use a Thread Pool with e.g. 10 Threads (depending on the machine) running and Distribute the connections evenly. Inside the Thread loop through the peers assigned to this Thread. And limit the maximum number of connections.
使用线程池，并且使用相当大的池大小（100 左右）应该是安全的。 CPU 不会成为问题，因为此类应用程序受 IO 限制。
您可以轻松配置池大小并设置合理的最大值，以防止所有线程出现与内存相关的问题。 当然，只有当所有线程都实际被使用时才会发生这种情况。
Use a thread pool and you should be safe with a fairly large pool size (100 or so). CPU will not be a problem since you are IO bound with this type of application.
You can easily make the pools size configurable and put in a reasonable maximum, just to prevent memory related issues with all the threads. Of course that should only occur if all the threads are actually being used.