*       listeners can harm responsiveness, slow the system as a whole, or worse. (See also the
   *       note about locking below.)
   *   <li>If many tasks will be triggered by the same event, one heavyweight task may delay other
   *       tasks -- even tasks that are not themselves {@code directExecutor} tasks.
   *   <li>If many such tasks are chained together (such as with {@code

   * segments, each governed by its own write lock. The segment lock is taken once for each explicit
   * write, and twice for each cache loading computation (once prior to loading the new value, and
   * once after loading completes). Much internal cache management is performed at the segment
   * granularity. For example, access queues and write queues are kept per segment when they are

    SettableFuture<String> future2 = SettableFuture.create();
    ListenableFuture<List<String>> compound = allAsList(future1, future2);
    // There was a bug where the event listener for the combined future would
    // result in the sub-futures being cancelled without being interrupted.
    ListenableFuture<List<String>> otherCompound = allAsList(future1, future2);

    if (hasLocalCache(cache)) {
      LocalCache<?, ?> map = toLocalCache(cache);
      for (Segment<?, ?> segment : map.segments) {
        drainRecencyQueue(segment);
      }
    }
  }

  static void drainRecencyQueue(Segment<?, ?> segment) {
    segment.lock();
    try {
      segment.cleanUp();
    } finally {
      segment.unlock();
    }
  }

  static void drainReferenceQueues(Cache<?, ?> cache) {

          <offlineLinks>
            <!-- We need local copies of some of these for 2 reasons: a User-Agent problem (https://stackoverflow.com/a/47891403/28465) and an SSL problem (https://issues.apache.org/jira/browse/MJAVADOC-507). If we choose to work around the User-Agent problem, we can go back to <links>, sidestepping the SSL problem. -->

 * specified the JVM flag {@code -XX:+DisableExplicitGC}. But in practice, it works very well for
 * ordinary tests.
 *
 * <p>Failure of the expected event to occur within an implementation-defined "reasonable" time
 * period or an interrupt while waiting for the expected event will result in a {@link
 * RuntimeException}.
 *
 * <p>Here's an example that tests a {@code finalize} method:
 *
 * <pre>{@code

   * segments, each governed by its own write lock. The segment lock is taken once for each explicit
   * write, and twice for each cache loading computation (once prior to loading the new value, and
   * once after loading completes). Much internal cache management is performed at the segment
   * granularity. For example, access queues and write queues are kept per segment when they are

          pages.

          This flag does not exist on 9-10 and 13+ (https://bugs.openjdk.java.net/browse/JDK-8215582).

          Consider removing it once our release and test scripts are migrated to a recent JDK (17+).
       -->
      <id>javadocs-jdk11-12</id>
      <activation>
        <jdk>[11,13)</jdk>
      </activation>
      <properties>

        Platform.tryWeakKeys(new MapMaker()).makeMap();

    private Integer getUid(Object obj) {
      Integer uid = uids.get(obj);
      if (uid == null) {
        // One or more integer values could be skipped in the event of a race
        // to generate a UID for the same object from multiple threads, but
        // that shouldn't be a problem.
        uid = counter.getAndIncrement();
        Integer alreadySet = uids.putIfAbsent(obj, uid);

      for (Segment<K, V> segment : segments) {
        if (segment.count != 0) {
          return false;
        }
        sum -= segment.modCount;
      }
      return sum == 0L;
    }
    return true;
  }

  long longSize() {
    Segment<K, V>[] segments = this.segments;
    long sum = 0;
    for (Segment<K, V> segment : segments) {