blocks|key|1538953|text|在大多数情况下，休眠线程消耗的资源将是它的堆栈空间。使用每个连接2个线程的模型，我认为它类似于您所描述的，由于这个原因，当连接数量增加时，会导致很大的可伸缩性问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1538954|我自己也遇到过这种情况，当连接数超过500时(大约1000个线程)，你往往会遇到很多OutOfMemoryError的情况，因为线程堆栈空间的使用量超过了单个进程的最大内存量。至少在我们的例子中，是在32位Windows上的Java世界中。我想，你可以调优一些东西，然后再做得更远一些，但是最终，由于你浪费了大量的内存，所以它的可扩展性并不是很好。|1538955|如果需要大量连接，可以使用Java+NIO+(新IO或其他任何东西)，这样就可以在同一线程中处理大量连接。|1538956|话虽如此，在一个相当现代的服务器上，100个以下的线程应该不会遇到太多问题，即使这可能仍然是对资源的浪费。|1538957|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

For most cases, the resources consumed by a sleeping thread will be its stack space. Using a 2-threads-per-connection-model, which I think is similar to what you're describing, is known to cause great scalability issues for this very reason when the number of connections grow large.

I've been in this situation myself, and when the number of connections grew above 500 connections (about a thousand threads), you tend to get into lots of cases where you get OutOfMemoryError, since the threads stack space usage exceeds the maximum amount of memory for a single process. At least in our case, which was in a Java on 32 bit Windows world. You can tune things and get a bit further, I guess, but in the end it's just not very scalable since you waste lots of memory.

If you need a large number of connections, Java NIO (new IO or whatever) is the way to go, making it possible to handle lots of connections in the same thread.

Having said that, you shouldn't encounter much of a problem with under a 100 threads on a reasonably modern server, even if it's probably still a waste of resources.

blocks|key|1753837|text|这不会有很好的可扩展性。拥有大量线程意味着虚拟机必须花费更多时间进行上下文切换，并且由于每个线程都需要自己的堆栈空间，因此内存使用率将会更高。使用较少的线程以流水线方式处理会更好，或者使用异步技术的线程池。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1753838|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This won't scale very well. Having a large number of threads means the VM has to spend more time context-switching, and memory useage will be higher due to each thread requiring its own stack space. You would be better off with a smaller number of threads processing in a pipeline fashion, or use the thread pool with asychronous techniques.

blocks|key|1539142|text|大量的线程等同于大量的堆栈空间，这将消耗你的内存-检查你的-Xss设置有多少，然后做数学计算。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539143|如果您曾经出于某种原因而不得不执行notifyAll()，那么您当然会唤醒大量额外的线程--尽管在您提出的体系结构中可能不需要这样做。|1539144|在这个模型中，我不确定是否可以轻松地避免每个侦听套接字都有一个线程(尽管我对NIO知之甚少--它甚至可能解决这个问题)，但请看一下java.util.concurrent.Executor接口及其实现类，以找到一种适当的方法来避免过多的额外线程。实际上，ThreadPoolExecutor可能也是管理侦听线程的好方法，因此您不必花费太多时间创建和销毁不必要的线程。|offset|length|style|CODE|1539145|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/javase/6/docs/api/java/util/concurrent/Executor.html^0|0|0|3J|I|1T|T|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@$F|U|G|V|H|I]]|9|@$F|W|G|X|1|Y]]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Lots of threads equate to lots of stack space, which will eat your memory - check out your -Xss settings for just how much, then do the math.

And if you ever have to do a notifyAll() for some reason, then of course you are waking up loads of extra threads - though you may not need to do that in your proposed architecture.

I'm not sure you can easily avoid having one thread per listening socket in this model (though I know very little about NIO - which might fix even that issue), but take a look at the <a href="http://java.sun.com/javase/6/docs/api/java/util/concurrent/Executor.html" rel="nofollow noreferrer">java.util.concurrent.Executor</a> interface and its implementing classes for a decent way to avoid having too many additional threads hanging around. Indeed, the <code>ThreadPoolExecutor</code> might be a good way to manage your listening threads too, so you don't spend too much time creating and destroying threads unneccessarily.

blocks|key|1539188|text|在我们切换到NIO之前，我们遇到了非常相同的问题，所以我将赞同Liedman的建议，采用该框架。你应该可以找到一个教程，但是如果你想知道细节，我可以推荐Ron+Hitchens的Java+NIO。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1539189|切换到NIO增加了我们可以处理的连接数量，这对我们来说真的很关键。|1539190|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0596002882^0|2H|8|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

We had very much the same problem before we switched to NIO, so I will second Liedmans recommendation to go with that framework. You should be able to find a tutorial, but if you want the details, I can recommend <a href="https://rads.stackoverflow.com/amzn/click/com/0596002882" rel="nofollow noreferrer" rel="nofollow noreferrer">Java NIO</a> by Ron Hitchens.

Swithcing to NIO increased the number of connections we could handle a lot, which was really critical for us.

blocks|key|1754076|text|根据我在C、Lua和Python中所做的测试，您可以使用很少的代码行来创建自己的睡眠或等待函数，从而创建一个简单的轻量级循环。使用一个带有您想要到达的未来时间的本地变量，然后在while循环中测试当前时间戳。如果您在使用fps的作用域中，请使等待函数每帧运行一次，以节省资源。如果您需要更高的精度，请考虑使用时钟而不是时间戳，因为时间戳被限制为秒。您向等待函数添加的代码行越多，它就会变得越不精确，消耗的资源也就越多，尽管10行以下的代码应该足够快。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1754077|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

From the tests I've done in C, Lua and Python, you can make your own sleep or wait function with very little lines of codes to make a simple lightweight loop.
Use a local variable with the time in the future you want to reach and then test for the current timestamp in a while loop. If you are in a scope where you work with fps, make the wait function run once per frame to save on resources.
The more precision you need, consider using the clock instead of the timestamp, since timestamp is limited to seconds.
The more lines of code you add into a wait function, the less precise it becomes and the more resources it consumes, although anything under 10 lines should be quick enough.

I'm wondering, how expensive it is to have many threads in waiting state in java 1.6 x64.

To be more specific, I'm writing application which runs across many computers and sends/receives data from one to another. I feel more comfortable to have separate thread for each connected machine and task, like 1) sending data, 2) receiving data, 3) reestablishing connection when it is dropped. So, given that there are N nodes in cluster, each machine is going to have 3 threads for each of N-1 neighbours. Typically there will be 12 machines, which comes to 33 communication threads.

Most of those threads will be sleeping most of the time, so for optimization purposes I could reduce number of threads and give more job to each of them. Like, for example. reestablishing connection is responsibility of receiving thread. Or sending to all connected machines is done by single thread.

So is there any significant perfomance impact on having many sleeping threads?

How much resources do sleeping and waiting threads consume

服务器

虚拟机

Windows

Python

Java

我想知道，在java1.6 x64中，让许多线程处于等待状态是多么的昂贵。更具体地说，我正在编写跨多台计算机运行的应用程序，并从一台计算机向另一台计算机发送/接收数据。我觉得每个连接的机器和任务都有单独的线程更舒服，比如1)发送数据，2)接收数据，3)当连接被丢弃时重新建立连接。因此，假设集群中有N个节点，对于N-1个...

问休眠和等待线程消耗了多少资源？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问休眠和等待线程消耗了多少资源？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问休眠和等待线程消耗了多少资源？
EN