assertThrows(IllegalArgumentException.class, () -> multiset.add(KEY, COUNT_TO_ADD));
  }

  /**
   * Simulate some of the races that can happen on add. We can't easily simulate the race that
   * happens when an {@link AtomicInteger#compareAndSet} fails, but we can simulate the case where
   * the putIfAbsent returns a non-null value, and the case where the replace() of an observed zero
   * fails.
   */

              || countMap.replace(element, existingCounter, newCounter)) {
            return 0;
          }
          break;
        }
      }

      // If we're still here, there was a race, so just try again.
    }
  }

  /**
   * Removes a number of occurrences of the specified element from this multiset. If the multiset

        assertTrue("Threads did not complete in time", doneLatch.await(5, TimeUnit.SECONDS));

        // All threads should fail with the same IOException (project ID is blank)
        // But importantly, there should be no race condition errors
        assertEquals(threadCount, failureCount.get());
        assertEquals(0, successCount.get());

        // All exceptions should be about project ID being blank

    the previous alpha due to an unexpected race.


## Version 5.0.0-alpha.5

_2022-02-21_

 *  Fix: Don't include [Assertk][assertk] in OkHttp's production dependencies. This regression was
    introduced in the 5.0.0-alpha.4 release.
 *  Fix: Don't ask `Dns` implementations to resolve strings that are already IP addresses.
 *  Fix: Change fast fallback to race TCP handshakes only. To avoid wasted work, OkHttp will not

    thread.join();
    // It's possible to race and suspend the thread just before the park call actually takes effect,
    // causing the thread to be suspended for 3.5 seconds, and then park itself for 2 seconds after
    // being resumed. To avoid a flake in this scenario, calculate how long that thread actually
    // waited and assert based on that time. Empirically, the race where the thread ends up waiting

        assertTrue("Threads did not complete in time", doneLatch.await(5, TimeUnit.SECONDS));

        // All threads should fail with the same IOException (endpoint is blank)
        // But importantly, there should be no race condition errors
        assertEquals(threadCount, failureCount.get());
        assertEquals(0, successCount.get());

        // All exceptions should be about endpoint being blank
        for (Exception e : exceptions) {

    thread.join();
    // It's possible to race and suspend the thread just before the park call actually takes effect,
    // causing the thread to be suspended for 3.5 seconds, and then park itself for 2 seconds after
    // being resumed. To avoid a flake in this scenario, calculate how long that thread actually
    // waited and assert based on that time. Empirically, the race where the thread ends up waiting

- Fixed a panic in `kubectl api-resources` that occurred when the Discovery Client failed. ([#134833](https://github.com/kubernetes/kubernetes/pull/134833), [@rikatz](https://github.com/rikatz))
- Fixed a possible data race during metrics registration. ([#134390](https://github.com/kubernetes/kubernetes/pull/134390), [@liggitt](https://github.com/liggitt)) [SIG Architecture and Instrumentation]

- Fixed a race condition in the kube-proxy initialization that could cause UDP traffic to service VIP. ([#126532](https://github.com/kubernetes/kubernetes/pull/126532), [@wedaly](https://github.com/wedaly))

- Fixed a startup probe race condition that caused main containers to remain stuck in "Initializing" state when sidecar containers with startup probes failed initially but succeeded on restart in pods with restartPolicy=Never. ([#134801](https://github.com/kubernetes/kubernetes/pull/134801), [@yuanwang04](https://github.com/yuanwang04)) [SIG Node and Testing]