* Careful here: if threads are mutating the atomicLongArray while this method is executing, the
     * final long[] will be a "rolling snapshot" of the state of the bit array. This is usually good
     * enough, but should be kept in mind.
     */
    public static long[] toPlainArray(AtomicLongArray atomicLongArray) {
      long[] array = new long[atomicLongArray.length()];
      for (int i = 0; i < array.length; ++i) {

 * multimap.put(key1, baz);
 * }
 *
 * ... the iteration order for {@link #keys()} is {@code [key1, key2, key1]}, and similarly for
 * {@link #entries()}. Unlike {@link LinkedHashMultimap}, the iteration order is kept consistent
 * between keys, entries and values. For example, calling:
 *
 * {@snippet :
 * multimap.remove(key1, foo);
 * }
 *

   * 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
   * required by the selected eviction algorithm. As such, when writing unit tests it is not
   * uncommon to specify {@code concurrencyLevel(1)} in order to achieve more deterministic eviction

  final Policy policy;

  private CycleDetectingLockFactory(Policy policy) {
    this.policy = checkNotNull(policy);
  }

  /**
   * Tracks the currently acquired locks for each Thread, kept up to date by calls to {@link
   * #aboutToAcquire(CycleDetectingLock)} and {@link #lockStateChanged(CycleDetectingLock)}.
   */
  // This is logically a Set, but an ArrayList is used to minimize the amount

## Version 5.0.0-alpha.7

_2022-04-26_

**This release introduces new Kotlin-friendly APIs.** When we migrated OkHttp from Java to Kotlin in
OkHttp 4.0, we kept our Java-first APIs. With 5.0 we're continuing to support Java and adding
additional improvements for Kotlin users. In this alpha we're excited to skip-the-builder for

   * concurrently readable hash table. The map supports non-blocking reads and concurrent writes
   * across different segments.
   *
   * The page replacement algorithm's data structures are kept casually consistent with the map. The
   * ordering of writes to a segment is sequentially consistent. An update to the map and recording
   * of reads may not be immediately reflected on the algorithm's data structures. These structures

 *     .writeTimeout(1000, TimeUnit.MILLISECONDS)
 *     .build();
 * ```
 *
 * This example shows a call with a short 500 millisecond read timeout and a 1000 millisecond
 * write timeout. Original configuration is kept, but can be overriden.
 *
 * ```java
 * OkHttpClient eagerClient = client.newBuilder()
 *     .readTimeout(500, TimeUnit.MILLISECONDS)
 *     .build();
 * Response response = eagerClient.newCall(request).execute();

add the word "Fixes" before the issue number or link.
Do not use "Fixes" if the PR is of kind `failing-test` or `flake`.

Reference KEPs when applicable in addition to specific issues.

Examples:
Fixes #<issue number>
<issue link> (issue in a different repository)
KEP: https://github.com/kubernetes/enhancements/issues/<kep-issue-number>

If there is no associated issue, then write "N/A".
-->

#### Special notes for your reviewer:

        A proposal that works through the design along with the implications of the change can be opened as a KEP.
        See https://git.k8s.io/enhancements/keps#kubernetes-enhancement-proposals-keps
    validations:
      required: true

  - type: textarea
    id: rationale
    attributes:
      label: Why is this needed?
    validations:

	([docs](http://kubernetes.io/docs/user-guide/federation/federated-replicasets.md))
	([kubernetes/features#46](https://github.com/kubernetes/enhancements/issues/46))
  - [beta] `Federated Secrets` are created and kept consistent across all clusters in a federation.
    ([docs](http://kubernetes.io/docs/user-guide/federation/federated-secrets.md))
    ([kubernetes/features#68](https://github.com/kubernetes/enhancements/issues/68))