Reviewed by the SEOPointz team · Last reviewed June 2026. We tested JVM tuning settings against load on a real Tomcat deployment before publishing this guide. SEOPointz may earn a commission from some links; it never changes what we recommend.
Java applications behave differently from a typical PHP site, and that difference is exactly why so many Java projects feel sluggish on the wrong host. A Java app runs inside a long-lived Java Virtual Machine (JVM) that holds memory, manages its own garbage collection, and often serves traffic through a servlet container like Apache Tomcat. Shared hosting that works fine for WordPress usually can’t give the JVM the dedicated memory and process control it needs. The real question isn’t “which host is fastest” — it’s whether your environment lets you control the JVM, and whether you’ve tuned it for your actual workload.
Why Java needs a different kind of hosting
Most serious Java apps need predictable CPU and RAM headroom plus the ability to set JVM flags, open custom ports, and configure a reverse proxy — things that are far easier on a VPS or cloud server than in a locked-down shared environment. On shared hosting you rarely get shell access or the right to set -Xmx, so the JVM is capped by the provider’s defaults. That’s the single most common reason a Java app that runs well locally crawls in production. If you’re weighing your options, our overview of managed web hosting pros and cons is a useful companion to this piece.
Get the heap size right
Heap sizing is where most Java performance problems start. Set the heap too small and the JVM spends excessive time garbage collecting, which stalls request handling; set it too large and you waste memory and can actually trigger longer pause times. As a rough starting point, applications under moderate load are often comfortable with 1–4 GB of heap, while high-demand systems may need 8–16 GB or more. Two flags matter most:
- -Xms — the initial heap size. Setting this equal to
-Xmxavoids the cost of the JVM resizing the heap at runtime. - -Xmx — the maximum heap size. Leave headroom on the server for the OS and non-heap memory; never set
-Xmxto the machine’s full RAM.
Treat these numbers as hypotheses, not gospel. The only honest way to size a heap is to measure your own app under realistic traffic.
Choose a modern garbage collector
The garbage collector you pick has a direct effect on latency. On multi-core servers, the G1 collector (enabled with -XX:+UseG1GC, and the default on modern JDKs) generally gives a good balance of throughput and predictable pauses. For latency-sensitive workloads with large heaps, the Z Garbage Collector (ZGC) is designed to keep pause times very low. If you’re still running an older Java release, upgrading to a current Long-Term-Support JDK — JDK 17 or JDK 21 — is one of the highest-return changes you can make, because each LTS brings real GC and runtime improvements.
Tune Tomcat, not just the JVM
If you serve through Tomcat, the container has its own bottlenecks separate from the JVM. The connector’s thread pool (maxThreads) caps how many concurrent requests you can handle; too low and requests queue, too high and you exhaust CPU and memory. Match it to your hardware and measured concurrency rather than copying a number from a blog. Keep keepAliveTimeout sane so idle connections don’t hog threads, and put a reverse proxy (Nginx or Apache) in front for TLS termination and static assets so the JVM only does what it’s good at.
Measure before and after every change
Never tune blind. Profiling tools like VisualVM, JConsole, and Java Mission Control show you actual heap usage and GC behaviour so you can see whether a change helped or hurt. Always test in a staging environment that mirrors production, change one variable at a time, and watch the metrics under load. A “best practice” flag that helps one app can quietly hurt another.
Hosting types for Java, compared
| Hosting type | JVM control | Best for | Trade-off |
|---|---|---|---|
| Shared hosting | Minimal — rarely lets you set JVM flags | Tiny apps, learning projects | Often too constrained for production Java |
| VPS (self-managed) | Full — tune flags, ports, proxy | Spring Boot APIs, JVM microservices, small enterprise apps | You handle OS, security, and updates |
| Managed cloud / PaaS | Moderate to full, depending on platform | Teams that want scaling without server admin | Higher cost; some platform constraints |
| Dedicated server | Full | Large, memory-heavy Tomcat deployments | Most expensive; you own all maintenance |
Providers such as HostArmada, IONOS, Hostinger, and VPSServer.com market Java-oriented VPS plans, and most support Spring, Hibernate, Maven, and Tomcat out of the box. Check the specific RAM allotment before committing — a cheap plan with too little memory will starve the JVM no matter how well you tune it.
Frequently asked questions
Can I run a Java app on cheap shared hosting?
Sometimes, but it’s usually a poor fit. Shared plans rarely give you shell access or the right to set JVM memory flags, so your heap is capped by the provider’s defaults. For anything beyond a hobby project, a VPS gives you the control Java needs.
How much RAM does a Java app need?
It depends entirely on the workload, but remember the JVM heap is only part of the picture — the OS, Tomcat, and non-heap memory all need room too. Size the heap from measured usage and leave clear headroom; don’t allocate the machine’s entire RAM to -Xmx.
Which JDK version should I deploy on?
Stick to a current Long-Term-Support release — JDK 17 or JDK 21 — for the best mix of performance, security patches, and modern garbage collectors. Upgrading from an old JDK is frequently the simplest performance win available.
Once your runtime is dialled in, it’s worth understanding the operating system underneath it: see why Linux web hosting is such a popular choice for JVM workloads, and revisit the pros and cons of managed web hosting if you’d rather not run the server yourself.
