Why do we need caching of Java objects? Can anyone give me a real world example that requires caching of objects? Also, give some points regarding caching design and types of caching and consequences of caching during multi threaded execution.What are all the APIs that supports caching in Java?
Why do I need separate Caching API since I can have plain java objects in memory.
You want to cache objects when the act of creating them is very expensive, this is true for reading data from disk vs ram at the hardware level all the way up to a high-level programming language like Java. If it takes 10ms to create an object, and 1ms to extract that object from a cache, provided that you re-use the objects you can either have 10ms + 1ms to create the object and re-use it, or 10ms + 10ms to create the object twice. The more re-use you have, the better caching performs.
When you write a multi-threaded program, you need to think about concurrent access to your objects, if you have a bank account object, and two threads read the balance and update it, you can end up with both threads reading the same value, and writing a new value based on that, so two deposits of £100 could result in your bank balance only incrementing by £100 as the second thread to update had a stale value for the current balance.
There are a lot of classes in the java.util.concurrent package to deal with concurrency as well as the synchronized keyword. There are lots of resources from Oracle here.
You do not need to cache objects, however you might want to do so to save memory, I/O and CPU resources etc.
The JVM for example might cache Integer objects, whenever you ask to create a new object, it might simply return a reference to an already existing object with the same value. Read more on the Flyweight pattern.
You can save on CPU resources by storing results that take lots of CPU to calculate, in a cache. Related technique: Memoization.
By caching some data in the application, you can save on I/O instead of hitting the database, hard drive, or network with each access.
Requested Example:
Suppose you're building a website where you need to display quotes of stocks, you will be reading them through a web API (network I/O). You are only required to have prices updated only once a minute (infrequent changes). Your website is being used by many users at once (concurrency/multithreading).
A caching solution can be to read the stock price once a minute, then keeping it in a thread-safe object. Each thread (represents requests from your concurrent users) will be reading from that object, instead of hitting the web API each time (network I/O savings).
The object is thread-safe, so the threads will not be reading that cached value in an inconsistent state while it is being updated each minute.
So each of the clients needs to wait for the other client to finish their task?
Sidenote: this is a concurrency issue and not so much a caching issue.
No, not necessarily, since there are thread-safe structures that will not block on reads. Further more in this example, there is only one thread that will update the object (the periodic one minute price update).
To elaborate, say we will cache those stock prices in a ConcurrentHashMap<String, BigDecimal> where the string represents the stock symbol, "GOOG", "ORCL", "MSFT" etc, and the BigDecimal represents the price/quote of the stock.
To serve your users you will be reading values from that map like this :
price = quotesMap.get("GOOG"); // get Google stocks quote
The ConcurrentHashMap.get() call is a thread-safe non-blocking (does not entail locking) call, and your multiple threads can do retrievals from the map concurrently.
The safety is insured by the fact that, all your get() calls will receive the latest completed update (done by your price updating thread when it calls ConcurrentHashMap.put() to update the prices cache).
Within a given user transaction, the same data may be requested multiple times. Try to reduce the number of redundant reads. Either pass the information around as method parameters or consider caching it on the session or thread context. Data that changes infrequently, such as meta data or configuration data, is good for caching. You can load the cache once at startup or on demand.