Member Avatar for warlord902

I have a kind of doubt, suppose I have a class like this:

public class AA{

    public static createUser(String a, int b){
        User usr=new User(a,b);
        BB.storeUser(usr);
    }
}

Now, if multiple threads call this createUser() method of this class at the same time, will it cause any kind of problem. Do I need to make it synchronous? It is not going to do any sophisticated task, it will just create a User object and call a function to store it.

  • 3 Contributors
  • 5 Replies
  • 197 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by warlord902

Dani AI

Generated

Short answer: a static method itself is not magically single-threaded — multiple threads can call it at once. The real question is whether the code touches shared mutable state. In ’s example the new User instance is a local object, so the potential race happens when that User is published (stored) by BB.storeUser. That is exactly what and pointed out: protect the shared data structure, not the mere act of calling a static method.

A few concise, practical points you can apply:

  • Make published objects immutable where possible (final fields). Immutable objects remove a whole class of visibility/race bugs:

    public final class User {
    private final String name;
    private final int id;
    public User(String name, int id) { this.name = name; this.id = id; }
    public String getName() { return name; }
    public int getId() { return id; }
}

  • Prefer thread-safe collections or atomic operations inside BB instead of broad external locks. Example using ConcurrentHashMap:

    private static final ConcurrentMap<String, User> users = new ConcurrentHashMap<>();
public static void storeUser(User u) {
    users.put(u.getName(), u); // thread-safe
}

  • For compound actions (check-then-act) use atomic helpers like computeIfAbsent, or guard a short synchronized block / ReentrantLock. Avoid synchronizing entire methods unless you need a global lock — synchronized static locks on the Class object and can become a scalability bottleneck.

Troubleshooting tip: if you see missing/inconsistent entries under load, reproduce with a stress test (many threads + CountDownLatch) and inspect invariants. Make BB own its concurrency policy so callers (like the static factory) stay simple and free of locking concerns.

Recommended Answers

All 5 Replies

Member Avatar for rubberman

This should be fine, but you probably want the BB storeUser() method to apply a lock to the data structure where it is placing the usr object.

Member Avatar for warlord902

This should be fine, but you probably want the BB storeUser() method to apply a lock to the data structure where it is placing the usr object.

Means unless we are updating or modifying something there is no need to make such methods synchronous?

Member Avatar for JamesCherrill

Means unless we are updating or modifying something there is no need to make such methods synchronous?

This will be true most of the time, but if you are accessing more than one value in such a method you may get inconsistent values for them when another thread modifies the data between the accesses. I agree with rubberman, the storeUser method should be synchronized on the target data store object.

Member Avatar for rubberman

Means unless we are updating or modifying something there is no need to make such methods synchronous?

As long as you are only using local, and not static or global variables in your method, you should be fine. As we have stated however, the storeUser() method should either be synchronous, or a lock applied to the data store. If the storeUser() method does a lot and being synchronous could introduce unnecessary latencies, then use a lock only for access to the data store.

Edited by rubberman because: n/a
Member Avatar for warlord902

Thanks a lot for the replies, :)
cleared my doubt

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.