7

I'm currently learning about actors in Scala. The book recommends using the react method instead of receive, because it allows the system to use less threads.

I have read why creating a thread is expensive. But what are the reasons that, once you have the threads (which should hold for the actor system in Scala after the initialization), having them around is expensive?

Is it mainly the memory consumption? Or are there any other reasons?

Community
  • 1
  • 1
rolve
  • 10,083
  • 4
  • 55
  • 75
  • Note that this question is about the overhead of threads *after* the creation, so it is not a duplicate of the linked question. Which is actually already stated in the question... – rolve Jul 04 '14 at 06:50

3 Answers3

10

Using many threads may be more expensive than you would expect because:

  • each thread consumes memory outside of heap which places restriction on how many threads can be created at all for JVM;
  • switch from one thread to another consumes some CPU time, so if you have activity which can be performed in a single thread, you will save CPU cycles;
  • there's JVM scheduler which has more work to do if there are more threads. Same applies to underlying OS scheduler;
  • at last, it makes little sense to use more threads than you have CPU cores for CPU-bound tasks and it makes little sense to use more I/O threads than you have I/O activities (e.g., network clients).
Victor Sorokin
  • 11,878
  • 2
  • 35
  • 51
  • 4
    it might be worth noting that the "JVM scheduler" comment implies your GC pauses will be somewhat increased (as it takes longer to bring all the threads to a safepoint), probably more noticeable on young gen pauses – Matt May 08 '12 at 14:06
2

Besides the memory overhead of having a thread around (which may or may not be small), having more threads around will also usually mean that the schedule will have more elements to consider when the time comes for it to pick which thread will get the CPU next.

Some Operating Systems / JVMs may also have constraints on the amount of threads that can concurrently exist.

Eventually, it's an accumulation of small overheads that can eventually account to a lot. And none of this is actually specific to Java.

Romain
  • 12,679
  • 3
  • 41
  • 54
2

Having threads around is not "expensive". Of course, it kinda depends on how many we're talking about here. I'd suspect billions of threads would be a problem. I think generally speaking, having a lot of threads is considered expensive because you can do more parallel work so CPU goes up, memory goes up, etc... But if they are correctly managed (pooled for example to protect the system resources) then it's ok. The JVM does not necessarily use native threads so a Java thread is not necessarily mapped to an OS native threads (i.e. look at green threads for example, or lightweight threads). In my opinion, there's no implicit cost to threads in the JVM. The cost comes from poor thread management and overuse of the resources by carelessly assigning them work.

mprivat
  • 21,582
  • 4
  • 54
  • 64