3

I'm using a thread pool that should be able to execute hundreds of concurrent tasks. However the tasks usually do very little computation and spend most of their time waiting on some server response. So if the thread pool size contains hundreds of threads just a few of them will be active while most of them will be waiting.

I know in general this is not a good practice for thread pools usage but the current design does not permit making my tasks asynchronous so that they can return the control without waiting for the server's response. So given this limitation I guess my biggest problem is increased memory consumption for the threads stack space.

So is there any way to use some kind of light-weight threads that does not consume much memory?

I now there's a JVM option -Xss to control the stacks memory but it's seems there's no way to control this per thread pool or thread only as opposed to changing it for all the threads inside the VM, right?

Also do you have any suggestions for a better solution to my problem?

Gray
  • 115,027
  • 24
  • 293
  • 354
Lobachevsky
  • 41
  • 3
  • From what I understand this threads perform network communication? – Marcio Aguiar Mar 16 '12 at 13:39
  • Yes, but unfortunately I don't have low-level control on the communication layer. – Lobachevsky Mar 19 '12 at 15:05
  • Just a note : Cached thred pools seem like a good fit for your use case, if the total number of threads is actually of concern. The caching would allow for a good thread reuse in case of activity spikes, and the time to live would allow them to get stopped (thus freeing resources) after a given amount of time. This would mitigate the issues (if you really do have one, e.g. 1000 threads is perfectly fine on typical current hardware). – GPI Aug 10 '17 at 14:21

2 Answers2

4

I know in general this is not a good practice for thread pools usage

I disagree. I think this is a perfect practice. Are you seeing problems with this approach, because otherwise, switching from standard threads, smacks of premature optimization to me.

So is there any way to use some kind of light-weight threads that does not consume much memory?

I think you are already there. Threads are relatively lightweight already and I see no reason to worry about hundreds of them unless you are working in a very constrained JVM.

Also do you have any suggestions for a better solution to my problem?

Any solution that I see would be a lot more complicated and would again be the definition of premature optimization. For example, you could use NIO and do your own scheduling of the thread when the server response was available but this is the sort of thing that you get for free with threads.

Gray
  • 115,027
  • 24
  • 293
  • 354
  • > I disagree. I think this is a perfect practice. Are you seeing problems with this approach because this smacks of premature optimization to me? – Lobachevsky Mar 19 '12 at 14:49
  • (Please ignore my comment above, it was by mistake) I haven't observed any real problems yet but I see that usually my thread pool has about 500 threads with only one or two of the threads active at a time. And now I need to increase the limits of my thread pool probably beyond 1000 so I was worried about the memory overhead. – Lobachevsky Mar 19 '12 at 14:59
  • You can kill that comment by clicking the X @Kostadin. If you see problems with memory or you suspect thrashing then I'd deal with it then. A good profiler will also tell you if you are having problems. I just created 2k threads in a test that took up <3mb of memory so the number of threads shouldn't be an issue. – Gray Mar 19 '12 at 15:04
  • Also the library I need to use does not support NIO at this time so unfortunately I cannot implement my own scheduling. – Lobachevsky Mar 19 '12 at 15:07
  • Thanks, Gray. I'll go ahead and make some tests then. – Lobachevsky Mar 19 '12 at 15:11
2

So is there any way to use some kind of light-weight threads that does not consume much memory?

Using plain threads in a thread pool is likely to be light weight enough.

I now there's a JVM option -Xss to control the stacks memory but it's seems there's no way to control this per thread pool or thread only as opposed to changing it for all the threads inside the VM, right?

This is the maximum size per thread. Its the size at which you want to get a StackOverFlowError rather than keep running. IMHO, There is little benefit in tuning this on a per thread basis.

The thread stack uses main memory for the portion which is actually used and virtual memory for the rest. Virtual memory is cheap if you have a 64-bit JVM. If this is a concern I would switch to 64-bit.

Also do you have any suggestions for a better solution to my problem?

If you have thousands of threads you might consider using non-blocking IO. It doesn't sound like you need to worry. In tests I have done, having 10,000 active threads consumes one CPU (if the threads are otherwise not doing anything) For every hundred threads, you could be wasting 1% of one CPU. This is unlikely to be a problem if you have spare CPU.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • OK, in that case I'll make some tests with increased thread pool size then and see if there are any problems. I didn't pay attention that the -Xss is just the max size. It should be fine then. – Lobachevsky Mar 19 '12 at 15:02