20

Is there any JSR or other serious initiative to create lightweight threads in Java? Something similar to Golang's goroutines or Erlang processes.

Java threads are known for their heavy weight. Something like 512-1024 kb per thread is used so this limits the maximum number of threads. Context switching between java threads also takes a "long" time.

I've heard of Quasar "fibers" (http://docs.paralleluniverse.co/quasar/) which are lightweight threads implemented as a lib. They seem a bit tricky to use though and haven't caught a lot of interest.

Ideally lightweight threads should be built into the core of the JVM.

DagR
  • 2,900
  • 3
  • 24
  • 36
  • 1
    Would you consider the master - worker pattern where threads are re-used? Perhaps a distrubuted version like Map Reduce or Hazelcast? – vikingsteve Dec 21 '16 at 11:12
  • I'm thinking of a single web server being able to process 100 000 simultaneous clients and keeping one (lightweight) thread per request and making synchronous calls to external systems for each client. – DagR Dec 21 '16 at 13:05
  • Shouldn't you allow the web server to handle that? In any case 100 000 simultaneous clients sounds like a lot so you'll be using some form of clustering anyways – vikingsteve Dec 21 '16 at 13:12
  • Related: http://stackoverflow.com/questions/20030120/java-default-stack-size – JimmyB Dec 21 '16 at 15:56

2 Answers2

10

There is a proposal for lightweight threads ("fibers") on the JVM called Project Loom: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html

It's in its early stages, nothing released yet, but still something to keep an eye on.

DagR
  • 2,900
  • 3
  • 24
  • 36
6

I am not aware of any "lightweight" solutions that would be on their way into the Java community process. See the jep entries ... no word about anything like that there. There was a request for coroutines years back; but that thing looks pretty much "dead".

I think the closest that you can get today would be more something like what the akka framework provides to you; as those Akka actors all run with a ""lightweight thread" of activity so to speak.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • 1
    In the beginning of Java, we had "green threads" which was a pure JVM implementation of threads but that was later replaced by kernel threads. – DagR Dec 21 '16 at 13:07
  • True, I vaguely remember seeing a lot of trouble with those thingies back then. But I *guess* those green threads weren't "lightweight" either ;-) ... but given your other comment, I think that Akka could be a good start for you. – GhostCat Dec 21 '16 at 13:10
  • 1
    Here's a quite insightful discussion about green vs native threads: http://softwareengineering.stackexchange.com/questions/120384/why-not-green-threads – DagR Dec 22 '16 at 19:03
  • 2
    Also "green threads" or "lightweight threads" would *de facto* be M:N scheduling. See https://en.wikipedia.org/wiki/Thread_%28computing%29#M:N_.28hybrid_threading.29 That's pretty much died out as a viable OS scheduling model for the reasons listed. – Andrew Henle Dec 22 '16 at 19:10
  • 1
    Virtual threads JEP looks like it https://openjdk.org/jeps/436 – Petr Gladkikh Dec 07 '22 at 13:17