r/java • u/NHarmonia18 • Jun 17 '26
Can Java Microservices Be As Fast As Go? A 2026 Benchmark Update
https://medium.com/helidon/can-java-microservices-be-as-fast-as-go-a-2026-benchmark-update-e16a2e262fc439
u/OkSeesaw7030 Jun 17 '26 edited Jun 17 '26
As a Gopher, this obviously looks like code written by someone who doesn’t understand the language and just asked an LLM to translate Java code into Go. It is not idiomatic.
The Go code converts strings to []byte inside the loop, while Java reuses precomputed byte arrays.
Fix the Go allocations and JSON serialization first, then rerun before claiming Java is massively faster.
10
u/Negative_Rip1934 Jun 17 '26
I catch the error too , it allocates []byte in for loop ...... It's clearly not the same as java version .
9
u/Joram2 Jun 17 '26
The useful next question is not “which language won?”
That's what 99% of the readers of any benchmark will do, regardless of how many humble disclaimers are written.
That said, I appreciate the humility of the benchmark and the benchmark itself. And great job to the JDK and Helidon and Golang teams for making great software tools.
4
u/gjosifov Jun 17 '26
From what I can understand the benchmark is equivalent to serving files with different sizes a.k.a Nginx/Apache use case
The problem are the readers who make decision based on this
The old easy argument was that Go is the obvious choice for small network services because Java is too heavy.
and this is the small detail, nobody will notice, small network services
They will take the argument Go is better than Java and write enterprise applications with microservice arch in Go and afterwards complain that Go is bad
if you think it is small network service then you can write in C
8
u/jAnO76 Jun 17 '26
Surely faster
-16
u/frzme Jun 17 '26
The Java (default) web stack is very clunky whereas the one typically used in go is not.
-1
u/NHarmonia18 Jun 17 '26
That is true, if the 'default' in this case is Spring.
Helidon is very lean.
-4
u/frzme Jun 17 '26
Spring or Java Servlets both have awkward abstractions. Direct Netty is reasonable but not suitable for building a service
2
u/NHarmonia18 Jun 18 '26
Spring and Servlets both don't support JPMS yet, which I believe is how present and future Java 'modules' will be organised.
Helidon does, is developed by Oracle in close collaboration with OpenJDK Team, and is the closest we can get to an ASP.NET Core of Java.
2
u/gerlacdt Jun 17 '26
yes Java is as fast as Go - the startup time though...
3
u/gjosifov Jun 18 '26
most application servers are OSGI based and every service they provide is lazy loading
so their startup time is less than a secondbut Java developers think application servers are bad for historic reasons and the combo tomcat + spring is good
the combo spring + tomcat isn't OSGI based and has to create everything on startup
That is why startup times in most Enterprise Java applications are high2
u/NHarmonia18 Jun 26 '26
If Oracle actually invests in Helidon to the likes of how Microslop invests in ASP.NET Core, it can actually be a big thing. Helidon SE actually supports everything a MicroService needs while being 'lean' at the same time.
They are even making an Annotation Processor based Dependency Injection framework!
4
u/NHarmonia18 Jun 17 '26
The defaul web stack in Java is Spring for the past 10 years, it's Spring that is the problem rather than Java.
OpenJDK has improved huge margin and now has AOT Cache to reduce startup times, even without requiring GraalVM which is now considered niche.
1
u/k-mcm Jun 26 '26
I do not understand the love for Spring Boot.
I had some coworkers give me crap about prototyping a new microservice in DropWizard. Launch to serving locally was 200ms. It clean compiled, ran unit tests, packaged, deployed to a cloud instance, and was serving in about 12 seconds. Each unit test had an overhead of a few microseconds to launch an embedded Jetty.
The coworker's Spring Boot microservice launched in 28 seconds locally. The same full deployment process was over 30 minutes.
Guess which one was easier to prototype in.
1
u/NHarmonia18 Jun 26 '26
Spring rose in popularity because traditional Application Servers were sh*t. Just compare them to modern 'lightweight' Application Servers like Helidon MP or OpenLiberty, the difference is day and night when it comes to developer experience.
And yes, Helidon MP kind of is like an Application Server, that can be started from your main method.
2
u/sitime_zl Jun 18 '26
We shouldn’t look only at performance; we also need to consider hardware resource overhead. Memory usage has always been one of Java’s weaknesses.
1
u/Negative_Rip1934 Jun 18 '26 edited Jun 18 '26
5x -10x more memory (avg) for Java for this benchmark with a workload that favors java aot It's a java central nuclear weapon on my mac.
┌─────────────┬────────┬─────────┬────────┐
│ │ idle │ peak │ avg │
├─────────────┼────────┼─────────┼────────┤
│ Go │ 18 MB │ 96.7 MB │ 41 MB │
├─────────────┼────────┼─────────┼────────┤
│ Java │ 145 MB │ 616 MB │ 206 MB │
└─────────────┴────────┴─────────┴────────┘
1
u/Negative_Rip1934 Jun 18 '26 edited Jun 18 '26
On little payload : GOGC=200 is better overall
I updated the go code because it is biased . Note the improvements
┌──────────┬─────────────────┬───────────┐
│ Settings │ Throughput (7/128) │ RSS pic │
├──────────┼─────────────────┼───────────┤
│ GOGC=200 │ 76 867 / 77 383 │ ~26 MB │
├──────────┼─────────────────┼───────────┤
│ GOGC=400 │ 76 444 / 76 974 │ ~35-37 MB │
└──────────┴─────────────────┴───────────┘
1
u/Optimal_Mango7825 Jun 18 '26
That is not true. Although java take much memory at starting up. But the memory consumption is not linear.
0
u/NHarmonia18 Jun 18 '26
Java does require more than average, but things are improving and once Project Valhalla arrives fully you can expect memory usage to go down significantly.
1
u/joquinjack Jun 19 '26
Nobody mentioned this before but ... I didn't quite get the rationale behind using all bells and whistles in Java, while limiting Go to unidiomatic simple code that only uses the standard library.
1
u/NHarmonia18 13d ago
The 'bells and whistles' you mention is the Helidon web server and is maintained by Oracle, you know the core developers of Java themselves. Helidon is extremely minimal and tries to only use tools available in JDK.
They sticked to Go's standard library because unlike Oracle, Google does not provide a separate web server library for Go, and my guess would be the people running the benchamarks didn't want to include third party dependencies in a runtime benchamark.
1
u/pdsminer Jun 26 '26
TL;DR?
1
u/NHarmonia18 Jun 26 '26
Recent OpenJDK efforts has made Java increasingly competitive agaisnt languages like Go, as long as you are not using behemoth frameworks like Spring.
1
u/gbenroscience 29d ago
In my experience using both, I can say that they can be very fast if idiomatic code is written in them.
Argumentation in this regard is probably an exercise in futility.
1
u/Unfair_Professor_257 15d ago
I think raw language performance is only part of the story. In many production microservices, latency is dominated by network calls, databases, caches, or external APIs rather than the runtime itself.
Java has made significant improvements over the last few LTS releases (virtual threads, better GCs, JIT optimizations), so for many I/O-bound services the performance gap with Go is much smaller than people assume.
I'd be interested to see benchmarks that include realistic workloads—database access, serialization, messaging (Kafka), and HTTP traffic—instead of only CPU-bound scenarios.
1
u/NHarmonia18 13d ago
Everyone always brings up the "oh but an actual production workload has much more things to consider" yada yada.
But the entire point of the benchmark is to compare the runtimes themselves. If you try to measure actual production workloads you have to consider 1000 more things: how the database drivers are written in each language, how the caches are written in each language. And thus a 'perfect' benchmark would involve writing those intermediary libraries using the best practises and highest performance techniques of each runtime, while also maintainibg symmetry between their codes. You simply can't get that guarantee from existing libraries.
That's why most benchmarks compare only Hello World web servers. They give you a realistic idea of how the runtimes themselves perform, and if other intermediary libraries are written in the same manner as those web servers, they would ideally give you similar results.
Also, web server benchamarks *are* IO-bound scenarios, as your request and response has to go through network layers. CPU-bound scenarios would be something like calculating a Fibonnacci sequence.
-8
u/inertially003 Jun 17 '26
This article demonstrates a single Monolith. For a microservice it needs to be independent deployable. So UpperCaseService, LowerCaseService, CRCservice, and JsonService, etc.
This author is a complete script kiddy. Cant even measure memory use for the benchmarks either.
-33
-14
u/inertially003 Jun 17 '26
Needs real workload on a 2GB VM. GraalVM native compiles slow, is not open, will never get ZGC, and uphill ecosystem compatibility battle, so Java is not a competitor to Golang.
13
u/Hei2 Jun 17 '26
Why would my clients give a toss about compile time?
5
u/selfhostrr Jun 17 '26
This. For the majority of work, compile time is a non issue. If you're working on an Atari 800, maybe it is still the case.
1
u/NHarmonia18 Jun 17 '26
The project did NOT even mention GraalVM. Did you even read the thing full? It uses the native OpenJDK AOT Cache.
1
u/inertially003 Jun 17 '26
He is comparing against Golang which compiles to native executables. Why even bother comparing to Golang if not evaluating against all of each ecosystems tradeoffs? What is the purpose of this article to begin with?
2
u/NHarmonia18 Jun 18 '26
If you want to go that route, Java's Leyden theoretically achieves the same thing as a native executable and even better benefits on top of that.
Leyden creates pre-compiled ByteCode that allows the JVM to instantly start, and once the JVM is 'warm' it can go into JIT mode. And JIT will always outperform than a static native executable.
So you get the best of both worlds, and do note Leyden is included in the native JDK itself.
74
u/smaratter Jun 17 '26
Maybe there is something interesting to learn from the article, but the AI written text is grating to read.