---
title: "Discussion on \"Go vs Java in terms of memory efficiency. Beauty of go routines and their variable stack size limit.\" | Hashnode"
description: "Discussion on \"Go vs Java in terms of memory efficiency. Beauty of go routines and their variable stack size limit.\". Concurrency can be achieved in different ways. Different languages/technologies take different approaches to achieve concurrency.\nFor example, C/C++, Java,etc. will create OS threads to achieve Concurrency. But they have fixed stack size. This limits..."
url: "https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Go vs Java in terms of memory efficiency. Beauty of go routines and their variable stack size limit.](https://hashnode.com/post/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit?utm_source=hashnode&utm_medium=feed)

Concurrency can be achieved in different ways. Different languages/technologies take different approaches to achieve concurrency. For example, C/C++, Java,etc. will create OS threads to achieve Concurrency. But they have fixed stack size. This limits...

Mar 12, 2019 · hashnode.com  
Updated Mar 14, 2019  
Read the article

-   [#go](https://hashnode.com/tag/go)
-   [#java](https://hashnode.com/tag/java)
-   [#stackoverflow](https://hashnode.com/tag/stackoverflow)
-   [#thread-vs-go-routine](https://hashnode.com/tag/thread-vs-go-routine)
-   [#java-vs-go](https://hashnode.com/tag/java-vs-go)

## Written by

[PRASHANTH H N](https://hashnode.com/@prahashnode)

@prahashnode · Bengaluru, Karnataka, India

  
[View profile](https://hashnode.com/@prahashnode)

Software Developer

## Responses 4

Markdown supported · ⌘↵ to post

[Ajinkya Borade](https://hashnode.com/@Ajinkya)

[Mar 29, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c9dd71ace38515309ac752b)

Im not exactly sure about Java mem stack limit and how it uses OS threads.

I will post this in context of GoLang (GO) just for the sake I wanted to write and I love Go, I hate Java (dont ask me why).

**goroutines** are not OS threads, but they are not exactly Green Threads as well.

Go’s mechanism for hosting goroutines is an implementation of what’s called an M:N scheduler , which means it maps M green threads to N OS threads.

Goroutines are then scheduled onto the green threads. When we have more goroutines than green threads available, the scheduler handles the distribution of the goroutines across the available threads.

[PRASHANTH H N](https://hashnode.com/@prahashnode)

[Apr 1, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c9dd71ace38515309ac752b#reply-5ca1875de9cf4f914baf8ee2)

Hi @Ajinkya Can you please give a reference to "M:N scheduler" part ?

[Ajinkya Borade](https://hashnode.com/@Ajinkya)

[Apr 1, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c9dd71ace38515309ac752b#reply-5ca19134e9cf4f914baf8ee6)

[PRASHANTH H N](https://hashnode.com/@prahashnode) [golang.org/src/runtime/proc.go](https://golang.org/src/runtime/proc.go)

easy to read => [ardanlabs.com/blog/2018/08/scheduling-in-go-part2…](https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part2.html) [povilasv.me/go-scheduler](https://povilasv.me/go-scheduler/)

[Ajinkya Borade](https://hashnode.com/@Ajinkya)

[Apr 8, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c9dd71ace38515309ac752b#reply-5caad238dbeca9f921c49d19)

more on this [rcoh.me/posts/why-you-can-have-a-million-go-routi…](https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-java-threads/)

[Vishwa Bhat](https://hashnode.com/@cruci161)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17)

There are several parts where I disagree with your points;

1.  All the programming languages must use _OS Thread(s)_ to achieve concurrency. It's just the approach to achieve the concurrency differs.
    
2.  You mentioned
    
    > Go does not create OS threads. Instead, it creates a much lighter go routines
    
    No, _you_ have to define a go-routine to achieve concurrency for which Go _schedules_ the task defined inside go-routine and it will be executed inside the pre-spawned _thread_ through the concept of _Communicating Sequential Process(CSP)_
    
3.  Goroutine is not a new concept. _Actors_(Scala), _Coroutines_(Kotlin), for that matter, it can be introduced in Java too, through a library -- _Quasar Fibers_ or _Scala Actors_ (interoperated). When you see any documentation mentioning _lightweight/green threads_, what they actually mean is to provide concurrency through scheduling the tasks instead of spawning new threads for each task. And to manage Stack size of several isolated tasks in a single thread is difficult wrt JVM based languages, particularly Java, whereas Golang smartly called it _segmented stack_ to dynamically grow the stack size because it directly utilises OS threads.
    

_Now comes my primary point:_

Why there is a relation established between Stack Size and Concurrency?

Let's look at the general definition of both. Stack Size is the capacity provided to store the function/procedure calls or in simple terms, the stack of line numbers of the function call hierarchy. Concurrency is the ability to perform tasks simultaneously such that idle resources are completely utilized regardless of no. of threads or CPUs. So, Stack-Size plays around the flow of the _function_ and Concurrency plays around the flow of _program-logic_. The only time both meets at a point is during _recursion_ but that's no where suffice to jump into conclusion on concurrency just because the stack-size of two languages are different.

_Talking about Web Server;_

I completely agree to the point that Golang handles incoming requests through go-routines but the Java neither spawns a new thread for each request nor it adds the request to the thread stack.

Earlier, Java used to have Thread-based Servers (until Servlets v4.0) where a Pool of Worker Threads are created initially and all the requests are delegated to that thread pool. This caused _C10K Problem -- Handling Concurrent 10K Connections_. This is where people used to Spin-up more Worker Threads in the Pool. In the recent years, the concept of _Multi-threaded Event pool_ concept is pretty common in all the Java Web Servers like Netty, Servlets 4.1+, Jersey etc. which acts like NodeJS event loops but multiple event loops. Long gone are the days where you _actually_ create threads.

The only places where Golang hits up is

1.  Memory consumption standpoint as you mentioned
2.  IO calls

In-case you want a benchmarks on the performance:

1.  [Web Server Performance](https://www.techempower.com/benchmarks/#section=data-r17&hw=cl&test=fortune)
2.  [Core Performance](https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html)

Having said that; I like both the languages. Java because of its stability and ecosystem and Golang because of its simplicity. Both are ridiculously performant, though IO is not Java's best suite because of blocking JDBC driver.

If anyone has different view on my comment, I'd be happy to discuss. :)

Cheers!

[Vishwa Bhat](https://hashnode.com/@cruci161)

[Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88ac5425dac18a3cef39e3)

[j](https://hashnode.com/@chilimatic) Rust is still in my learning basket, I heard it's worthy to learn.

[PRASHANTH H N](https://hashnode.com/@prahashnode)

[Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88c3f86ac67d214c92d727)

I thought C# does not require any VM. It is very interesting to know that it requires VM to run. By the way I do not know anything about C#. Iss't it a compiled language where in we can build .exe and .dlls ? As [j](https://hashnode.com/@chilimatic) is telling that it requires VM then I wonder what will be the format of file that we finally build to run a C# program !

[j](https://hashnode.com/@chilimatic)

[Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88e59a8d5c82cc615ceb38)

[Vishwa Bhat](https://hashnode.com/@cruci161) I am organizing a rust meetup and I really like the language. I leave the decision up to you :D

[PRASHANTH H N](https://hashnode.com/@prahashnode) [stackoverflow.com/questions/9556354/if-c-sharp-is…](https://stackoverflow.com/questions/9556354/if-c-sharp-is-not-interpreted-then-why-is-a-vm-needed) :) don't confuse the runtime with a vm :)

[j](https://hashnode.com/@chilimatic)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185)

well that's kinda true if you don't take the

```
-Xss1024m
```

attribute into account because now java also has 1GB stack size.

also it depends heavily on the architecture. And I do like go more than Java.

Also it's unfair to compare a JIT / Runtime based system with a baremetal binary.

[Mark](https://hashnode.com/@mverleg)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185#reply-5c87970d2fed1e9e73535078)

But if anything, having a dynamically sized stack should be easier on a VM, right?

[j](https://hashnode.com/@chilimatic)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185#reply-5c879d7c8ed8afd37616074f)

[Mark](https://hashnode.com/@mverleg) well it depends on the architecture of the vm since the vm is just an abstraction to support multiple 'baremetal machines' below.

to be honest I am not quite sure what 'is easier' because using a normal stack based programming language probably is 'the easiest way'.

it's just a different compile target in the end. The OS-Kernel seams to be more relevant since even a 'dynamically sized stack' which in the end usually means either big memory copies or some type of pointer / fat pointer / reference / ... to the heap.

The thing about java is that as long as objects usually always live on the heap and are passed in as references. the only stack based variables you have are primitives like int for example.

but back to the point the allocation of memory is up to the VM so it can be seen easier from certain applied perspectives. The optimization and allocation is not really part of your application model anymore if you mean this with easier.

I think I need to read up on this a little more :) these are just my unfiltered thoughts. and i actually deleted a lot because I am sure I went off track with transformation problems and cpu architecture etc. call windows, stack based languages and such ;D ....

[PRASHANTH H N](https://hashnode.com/@prahashnode)

[Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185#reply-5c8873efccbad0dc0937acb7)

Yes, java allocates memory in heap for every object that we create. But the thread that it creates will receive a fixed amount of stack size which may not be required at all.

[Mark](https://hashnode.com/@mverleg)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87716ec1bd71485918419f)

Wasn't this already posted? It looks familiar.

Interesting though!

[j](https://hashnode.com/@chilimatic)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87716ec1bd71485918419f#reply-5c8779351d0e3dd05d9f216f)

[Mark](https://hashnode.com/@mverleg) it was node last time.

[PRASHANTH H N](https://hashnode.com/@prahashnode)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87716ec1bd71485918419f#reply-5c87797c1d0e3dd05d9f2172)

The previous post was between nodejs and go. I had wrong understanding of node. I though node will spwan a thread per client which is not right. But this post is between java and go. I am not conveying anything wrong here.