* message must mention two values that were associated with the duplicate key in two different
   * calls to Builder.put (though we don't really care *which* two values if there were more than
   * two). These considerations lead us to have a field of type DuplicateKey in the Builder, which
   * will remember the first duplicate key we encountered. All later calls to buildOrThrow() can

        helper = new SynchronizedHelper();
      }
    }
    ATOMIC_HELPER = helper;

    // Prevent rare disastrous classloading in first call to LockSupport.park.
    // See: https://bugs.openjdk.java.net/browse/JDK-8074773
    @SuppressWarnings("unused")
    Class<?> ensureLoaded = LockSupport.class;

   *       terminate whichever thread happens to trigger the execution.
   * </ul>
   *
   * A specific warning about locking: Code that executes user-supplied tasks, such as {@code
   * ListenableFuture} listeners, should take care not to do so while holding a lock. Additionally,
   * as a further line of defense, prefer not to perform any locking inside a task that will be run

    try {
      builder.buildOrThrow();
      fail("Expected exception from duplicate keys");
    } catch (IllegalArgumentException expected) {
      // We don't really care which values the exception message contains, but they should be
      // different from each other. If buildKeepingLast() collapsed duplicates, that might end up
      // not being true.