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?