In-memory caching objects in java

Question

I want to cache objects in memory. The requirements are as follows:

1. Every record/object is associated with a unique key.
2. 400-500 records/objects to be stored. If the number of records increase beyond the specified limit, then the older records should be evicted.
3. Records shouldn't be stored beyond 2 mins.
4. Should scale down when JVM is running out of memory (kind of weak reference).
5. Third party library cannot be used because its a small module and the intention is just to decrease the unnecessary network access.
6. There are more writes, less reads

Security is also a concern here because we are going to cache some sensitive data. This data will be cached in memory. Should I really worry about the security and encrypt the data?

I am looking for a Java class which provides a similar functionality.

Currently I am thinking of extending WeakHashMap, and implementing various private/public methods to adhere to the requirements.

If you have any other idea please share here.

Answer 1

You don't want to use WeakHashMap. SoftHashMap would be closer but is not available in the standard library. If I were you I'll look at Guava's cache classes for hints.

But here are some additional thoughts:

Should scale down when JVM is running out of memory(kind of weak reference).

You mean soft reference. But anyways, this requirement smells a bit to me. It can be a valid requirement I'd admit, but it's rare that you really need this. If the size of your records can be reasonably well predicted and if you are planning to have a hard limit on number of records you want to cache, chances are that you don't need this complexity.

Third party library shouldn't be use.

Everybody mentioned this, and they're right.

On the security aspect, efficacy of encrypting data cached in-memory is dubious. You'll have to have the encryption key in-memory as well. I bet there are many things to worry more than attackers reading your memory content.

Answer 2

No, you should not do this. WeakHashMap is not a cache!

Now it is easy to understand why the WeakHashMap doesn't work for caching. First of all it wouldn't work anyway because it uses soft references for the keys and not for the map values. But additional to that, the garbage collector aggressively reclaims the memory that is referenced only by weak references. It means that once you lose the last strong reference to an object that is working as a key in a WeakHashMap, the garbage collector will soon reclaim that map entry.

...

So how the hell do I implement a cache in Java?

My suggestion is to use one of the freely available Cache implementations, like JCS, OSCache and others. Those libraries provide better memory management with LRU and FIFO policies for instance, disk overflow, data expiration and many other optional advanced features.

As @user463324 mentions, you should just use a library that already implements this, like Google Guava, which is under the Apache 2.0 license, which no sane business would have a problem with. Not invented here is not a good reason to ignore a solution.

Answer 3

You have two options: JCS or Memcache/EHCache

The two options are functionally equivalent but have some critical differences. When you use JCS, the cached objects are not serialized/deserialized. They remain as java objects, hence storing and retrieving them is very fast. However, this means, your cache is inside the JVM, hence using the JVM's heap, and also not accessible to other JVMs. [JCS provides some type of distributed capability as an addon].

On the other hand, Memcache/Ehcache are external caches that perform serialization/deserialization while doing the put/get operations. This could negate the benefit of caching in some extreme cases. so benchmarking for speed is essential. If it is suitable, it is distributed, it uses its own memory, could be on another box. But that also means, you have to consider the security of data between the JVM and the external cache.