Question

I think i have a pretty good idea about the volatile keyword in java, but i’m thinking about re-factoring some code and i thought it would be a good idea to use it.

i have a class that is basically working as a DB Cache. it holds a bunch of objects that it has read from a database, serves requests for those objects, and then occasionally refreshes the database (based on a timeout). Heres the skeleton

public class Cache
{
    private HashMap mappings =....;
    private long last_update_time;
    private void loadMappingsFromDB()
    {
        //....
    }
    private void checkLoad()
    {
        if(System.currentTimeMillis() - last_update_time > TIMEOUT)
            loadMappingsFromDB();
    }
    public Data get(ID id)
    {
        checkLoad();
        //.. look it up
    }
}

So the concern is that loadMappingsFromDB could be a high latency operation and thats not acceptable, So initially i thought that i could spin up a thread on cache startup and then just have it sleep and then update the cache in the background. But then i would need to synchronize my class (or the map). and then i would just be trading an occasional big pause for making every cache access slower.

Then i thought why not use volatile

i could define the map reference as volatile

private volatile HashMap mappings =....;

and then in get (or anywhere else that uses the mappings variable) i would just make a local copy of the reference:

public Data get(ID id)
{
    HashMap local = mappings;
    //.. look it up using local
}

and then the background thread would just load into a temp table and then swap the references in the class

HashMap tmp;
//load tmp from DB
mappings = tmp;//swap variables forcing write barrier

Does this approach make sense? and is it actually thread-safe?

Answer 1

There’s some misinformation in the existing answers to this question. Use of volatile actually is a good step in ensuring thread safety. See item 3 in Dispelling Java programming language myths by IBM’s Peter Haggar. Haggar gives a bit of background and an example, but the nut is this:

So, how can atomic operations not be thread safe? The main point is that they may indeed be thread safe, but there is no guarantee that they are. Java threads are allowed to keep private copies of variables separate from main memory.

By using volatile, you will guarantee that threads are referring to main memory and not using private copies of variables that you don’t know about or expect.

To answer your question, then: yes, your strategy is safe.

EDIT:
In response to another post, here is the JLS section about volatile fields.