CODEWITHSUNDEEP
javathread-safety
GorillaApe
GorillaApe

Reputation: 3641

Java static and thread safety or what to do

I am extending a library to do some work for me. Here is the code:

public static synchronized  String decompile(String source, int flags,UintMap properties,Map<String,String> namesMap)
    {
        Decompiler.namesMap=namesMap;
        String decompiled=decompile(source,flags,properties);
        Decompiler.namesMap=null;
        return decompiled;

    }

The problem is that namesMap is static variable. Is that thread safe or not? Because if this code runs concurently namesMap variable may change. What can I do for this?

Upvotes: 3

Views: 306

Answers (4)

Winter
Winter

Reputation: 1490

There will only be one namesMap so you don't have to worry whether it would use the same namesMap. It would.

Upvotes: 0

GorillaApe
GorillaApe

Reputation: 3641

Actually Decompiler.namesMap=namesMap; is the only place to set namesMap

But nowhere else in the code the namesMap is changed.. Only read...

I want to ensure that 

String decompiled=decompile(source,flags,properties);

would use the same namesMap.

Upvotes: 0

T.J. Crowder
T.J. Crowder

Reputation: 1074949

The method decompile is thread-safe (it will never be running on two threads concurrently), but if anything other than that method also uses the namesMap, then no, overall this is not thread-safe: Another method other than decompile running on a different thread could modify the map while the decompile method is using it, presumably causing mayhem. :-)

You might look at the classes in the java.util.concurrent namespace (for instance, ConcurrentHashMap) to see if any of those are applicable to what you're doing.

Edit (Responding to your comment.) If the static member namesMap is only ever used by decompile and not by anything else (you don't get a reference to it to anything else, etc.), then you're fine. The fact it's a static doesn't matter, if the only place it's used is serialized.

Upvotes: 5

matt b
matt b

Reputation: 139961

If there is a chance that other threads will make changes to namesMap while the method decompile(String, int, UintMap, Map) as described above is running, then you should be making a copy of the map passed in rather than just assigning a reference.

Decompiler.namesMap= new HashMap<String, String>(namesMap);

If there is a chance that other threads will make changes to the elements contained within the map, and not just the structure of the map itself, then you should make sure that your decompile() method and the other threads using namesMap are guarded by the same lock.

Upvotes: 1

Related Questions