我正在使用一个应该能够执行数百个并发任务的线程池。但是，这些任务通常只进行很少的计算，并且大部分时间都在等待一些服务器响应。因此，如果线程池大小包含数百个线程，则其中一些线程将处于活动状态，而大多数线程将等待。
我知道这通常不是线程池使用的好习惯，但是当前的设计不允许我的任务异步，以便他们可以在不等待服务器响应的情况下返回控件。所以考虑到这个限制，我想我最大的问题是增加了线程堆栈空间的内存消耗。
那么有没有办法使用某种不消耗大量内存的轻量级线程？
我现在有一个JVM选项-Xss来控制堆栈内存，但似乎没有办法控制每个线程池或线程，而不是为VM中的所有线程更改它，对吧？
您是否有任何建议可以更好地解决我的问题？
答案 0 :(得分：2)
我知道一般来说这不是线程池使用的好习惯
我不同意。我认为这是一个完美的做法。你是否看到了这种方法的问题，因为否则，从标准线程切换到我的过早优化？
那么有没有办法使用某种不消耗大量内存的轻量级线程？
我想你已经在那里了。线程已经相对轻量级了，除非你在一个非常有限的JVM中工作，否则我认为没有理由担心数百个。
您是否有任何建议可以更好地解决我的问题？
我看到的任何解决方案都会是 lot 更复杂，并且会再次成为过早优化的定义。例如，你可以使用NIO并在服务器响应可用时自己调度线程，但这是你通过线程免费获得的东西。
答案 1 :(得分：1)
那么有没有办法使用某种不消耗大量内存的轻量级线程？
在线程池中使用纯线程可能足够轻。
我现在有一个JVM选项-Xss来控制堆栈内存，但似乎没有办法控制每个线程池或线程，而不是为VM中的所有线程更改它，对吧？
这是每个线程的最大大小。它是您希望获得StackOverFlowError而不是继续运行的大小。恕我直言，在每个线程的基础上调整它没什么好处。
线程堆栈使用主内存作为实际使用的部分，其余部分使用虚拟内存。如果您有64位JVM，虚拟内存很便宜。如果这是一个问题，我会切换到64位。
您是否有任何建议可以更好地解决我的问题？
如果您有数千个线程，则可以考虑使用非阻塞IO。这听起来不像你需要担心。在我已经完成的测试中，有10,000个活动线程消耗一个CPU（如果线程没有做任何事情）对于每100个线程，你可能浪费1％的一个CPU。如果你有备用CPU，这不太可能是一个问题。