*     directly, or use a combination of {@link #throwIfUnchecked} and {@code throw new
   *     RuntimeException(e)}. But consider whether users would be better off if your API threw a
   *     different type of exception. For background on the deprecation, read <a
   *     href="https://goo.gl/Ivn2kc">Why we deprecated {@code Throwables.propagate}</a>.
   */
  @CanIgnoreReturnValue

   *
   * <p><b>Performance note:</b> When feasible, {@code initialCapacity} should be the exact number
   * of values that will be added, if that knowledge is readily available. It is better to guess a
   * value slightly too high than slightly too low. If the value is not exact, the {@link
   * ImmutableIntArray} that is built will very likely occupy more memory than strictly necessary;

   *     directly, or use a combination of {@link #throwIfUnchecked} and {@code throw new
   *     RuntimeException(e)}. But consider whether users would be better off if your API threw a
   *     different type of exception. For background on the deprecation, read <a
   *     href="https://goo.gl/Ivn2kc">Why we deprecated {@code Throwables.propagate}</a>.
   */
  @CanIgnoreReturnValue

 * </ul>
 *
 * Guava contains a number of other multimap implementations, such as {@link ArrayListMultimap}. In
 * new code, we recommend using {@link MultimapBuilder} instead: It provides better control of how
 * keys and values are stored.
 *
 * <h3>Other Notes</h3>
 *
 * <p>As with {@code Map}, the behavior of a {@code Multimap} is not specified if key objects

   *
   * <p><b>Performance note:</b> When feasible, {@code initialCapacity} should be the exact number
   * of values that will be added, if that knowledge is readily available. It is better to guess a
   * value slightly too high than slightly too low. If the value is not exact, the {@link
   * ImmutableDoubleArray} that is built will very likely occupy more memory than strictly

    Builder<String, Integer> builder =
        ImmutableSortedMap.<String, Integer>naturalOrder()
            .put("one", 1)
            .put("one", 2); // throwing on this line would be even better

    try {
      builder.build();
      fail();
    } catch (IllegalArgumentException expected) {
    }
  }

  public void testOf() {

   *
   * <p>If {@code expectedSize} is exactly the number of elements added to the builder before {@link
   * Builder#build} is called, the builder is likely to perform better than an unsized {@link
   * #builder()} would have.
   *
   * <p>It is not specified if any performance benefits apply if {@code expectedSize} is close to,
   * but not exactly, the number of elements added to the builder.

        // condition efficiently without _introducing_ deadlock is probably
        // tricky. For now, just accept the race condition---missing a warning
        // now and then is still better than having no deadlock detection.
        allowedPriorLocks.put(acquiredLock, new ExampleStackTrace(acquiredLock, this));
      } else {
        // Unsafe acquisition order detected. Create and cache a

  //    monitor.enterXXX()/monitor.leave() will make it really clear
  //    which lock is held at any point in the code.
  //
  // 3. I think "enterWhen(notEmpty)" reads better than "notEmpty.enter()".
  //
  // TODO(user): Implement ReentrantLock features:
  //    - toString() method
  //    - getOwner() method
  //    - getQueuedThreads() method
  //    - getWaitingThreads(Guard) method

  /*
   * If n <= millerRabinBases[i][0], then testing n against bases millerRabinBases[i][1..] suffices
   * to prove its primality. Values from miller-rabin.appspot.com.
   *
   * NOTE: We could get slightly better bases that would be treated as unsigned, but benchmarks
   * showed negligible performance improvements.
   */
  private static final long[][] millerRabinBaseSets = {
    {291830, 126401071349994536L},