如何在创建java.util.logging.Logger之前检查它是否已经存在？

Question

I am running into a java.util.logging deadlock that I suspect is related to the way that I am checking for the existence of a Logger before (possibly) creating it.

My question is: What is the best way to check—in a threadsafe manner—for a Logger 's existence before creating it, and to block some other thread's inadvertent creation of that Logger in the meantime?

Background: java.util.logging.Logger#getLogger(String, String) will (atomically, in a thread-safe manner) look up a named Logger if one exists, and create it if it doesn't. But in my case, I want to check to see if the Logger is there already before setting about doing some complicated ResourceBundle locating/reparenting. Then, after my ResourceBundle is set up, and I know it's valid, I want to supply its name to the Logger#getLogger(String, String) call.

I need this ResourceBundle locating/reparenting to happen only if indeed a Logger does not exist. I need to have this whole thing happen atomically so that some other thread doesn't do a Logger#getLogger(String, String) call while I'm in the middle of setting up my ResourceBundle —I don't want the other thread to sneak in there and use a different ResourceBundle name, for example, thus invalidating all my hard work.

The idiom I had was something like this:

Logger logger = null;
final LogManager logManager = LogManager.getLogManager();
assert logManager != null;
synchronized (logManager) {
  // This method call finds the logger, but doesn't create one.
  logger = logManager.getLogger(myLoggerName);
  if (logger == null) {
    // no logger found; time to do expensive ResourceBundle lookup/parenting/etc.
    // ...time passes...
    logger = Logger.getLogger(myLoggerName, myResourceBundleNameIJustCalculated);
  }
}
assert logger != null;

This resulted in deadlock.

While my code was locked on the global LogManager , another thread innocently executing a totally unrelated Logger.getLogger(name) call thereby acquired the lock on the Logger.class object ( Logger#getLogger(String, String) is a static and synchronized method.) So this thread has the lock on Logger.class ...which my thread (as you can see above) needs in order to run his Logger.getLogger(name, resourceBundleName) call. Internally, Logger.getLogger(name) grabs the lock on the global LogManager . Voila. Deadlock.

I think that the way to prevent this is to follow the time-honored tradition of acquiring all locks in the same order. From what I can tell, simply surrounding my synchronized block with another synchronized block—but this time on Logger.class —should do the trick. Does that seem right? That is:

synchronized (Logger.class) {
  synchronized (globalLogManager) {
    // Hypothesis: this grabs locks in the same order
    // that java.util.logging classes use.  Should prevent
    // deadlocks?
  }
}

Thanks for your time and attention!

Answer 1

Do not lock an object that you do not control; this can lead to problems. Alternatively, you could use a different object that you control, such as a Map<String, Logger> . You can use a normal java.util.HashMap<String, Logger> along with a synchronized block in the same way you're using the log manager.

// import java.util.*;
// import java.util.logging.*;
final static Map<String, Logger> loggers = new HashMap<String, Logger>();

Logger logger;
synchronized(loggers) {
    logger = loggers.get(myLoggerName);
    if (logger == null) {
        // ... your expensive computation ...
        logger = Logger.getLogger(myLoggerName, myResourceBundleName);
        loggers.put(myLoggerName, logger);
    }
}

Answer 2

Since it the getLogger and addLogger calls are already synchronized for you, I don't think synchronizing that block is buying you anything. I would just remove the synchronization.