That depends on what you're creating and how. For better or worse[1], not everything follows the one-enormous-process Java way of doing things.

Btw, Redis is extremely fast to set up, but as I sai, if all you need is a HashMap..

[1] - Almost always for the better if you ask me. That Java "enterprisy" way of development is the worst thing I have ever experienced in computing ;)

Even multiple threads - any sort of concurrent access/modification on the same dataset becomes problematic if you just use a HashMap.

Sites that have any kind of download/upload component, even though does not have too much traffic, will need to serve multiple requests using threads/processes.

That is where we normally use relational database. However Redis presents a way to be faster than conventional databases by storing everything in memory. This is as close to a concurrency-safe HashMap that you can get with the least amount of effort.

But Java comes with several currency-safe hash-maps and trees and such - where have you been?

If you think that blocking TCP calls to a redis server that serialises everything is going to be faster than a `new HashSplayTree<String>()` you're absolutely bonkers.

"This is as close to a concurrency-safe HashMap that you can get with the least amount of effort."

No, it's more effort than using a concurrency-safe HashMap in a JVM process.