title: How can I check to see if a java.util.logging.Logger already exists before creating it?
body: <p>I am running into a <code>java.util.logging</code> deadlock that I suspect is related to the way that I am checking for the existence of a <code>Logger</code> before (possibly) creating it.</p>
  
  <p>My question is: <strong>What is the best way to check—in a threadsafe manner—for a <code>Logger</code>'s existence before creating it, and to block some other thread's inadvertent creation of that <code>Logger</code> in the meantime?</strong></p>
  
  <p>Background: <code>java.util.logging.Logger#getLogger(String, String)</code> will (atomically, in a thread-safe manner) look up a named <code>Logger</code> if one exists, and create it if it doesn't.  But in my case, I want to check to see if the <code>Logger</code> is there already before setting about doing some complicated <code>ResourceBundle</code> locating/reparenting.  Then, after my <code>ResourceBundle</code> is set up, and I know it's valid, I want to supply its name to the <code>Logger#getLogger(String, String)</code> call.</p>
  
  <p>I need this <code>ResourceBundle</code> locating/reparenting to happen only if indeed a <code>Logger</code> does not exist.  I need to have this whole thing happen atomically so that some other thread doesn't do a <code>Logger#getLogger(String, String)</code> call while I'm in the middle of setting up my <code>ResourceBundle</code>—I don't want the other thread to sneak in there and use a <em>different</em> <code>ResourceBundle</code> name, for example, thus invalidating all my hard work.</p>
  
  <p>The idiom I had was something like this:</p>
  
  <pre><code>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;
  </code></pre>
  
  <p>This resulted in deadlock.</p>
  
  <p>While my code was locked on the global <code>LogManager</code>, another thread innocently executing a totally unrelated <code>Logger.getLogger(name)</code> call thereby acquired the lock on the <code>Logger.class</code> object (<code>Logger#getLogger(String, String)</code> is a <code>static</code> and <code>synchronized</code> method.)  So this thread has the lock on <code>Logger.class</code>...which my thread (as you can see above) needs in order to run <em>his</em> <code>Logger.getLogger(name, resourceBundleName)</code> call.  Internally, <code>Logger.getLogger(name)</code> grabs the lock on the global <code>LogManager</code>.  Voila.  Deadlock.</p>
  
  <p>I <em>think</em> 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 <em>my</em> <code>synchronized</code> block with <em>another</em> <code>synchronized</code> block—but this time on <code>Logger.class</code>—should do the trick.  Does that seem right?  That is:</p>
  
  <pre><code>synchronized (Logger.class) {
    synchronized (globalLogManager) {
      // Hypothesis: this grabs locks in the same order
      // that java.util.logging classes use.  Should prevent
      // deadlocks?
    }
  }
  </code></pre>
  
  <p>Thanks for your time and attention!</p>