*
 * <p>It is possible to configure a {@code RateLimiter} to have a warmup period during which time
 * the permits issued each second steadily increases until it hits the stable rate.
 *
 * <p>As an example, imagine that we have a list of tasks to execute, but we don't want to submit
 * more than 2 per second:
 *
 * <pre>{@code
 * final RateLimiter rateLimiter = RateLimiter.create(2.0); // rate is "2 permits per second"

  //
  // TODO(user): Change API to make it impossible to use a Guard with the "wrong" monitor,
  //    by making the monitor implicit, and to eliminate other sources of IMSE.
  //    Imagine:
  //    guard.lock();
  //    try { /* monitor locked and guard satisfied here */ }
  //    finally { guard.unlock(); }
  // Here are Justin's design notes about this:
  //

        companies, or even industries — utilities useful for a sizable proportion of all Java
        programmers everywhere. If you can give enough detail such that any of us can imagine coming
        across a similar need in our own work, that's extremely helpful in studying how broadly
        useful the proposed change will be.

  - type: textarea
    attributes:
      label: Concrete Use Cases

  @Override
  public void tearDown() throws Exception {
    /*
     * Clear interrupt for future tests.
     *
     * (Ideally we would perform interrupts only in threads that we create, but
     * it's hard to imagine that anything will break in practice.)
     */
    clearInterrupt();
    aggregateFutureLogger.removeHandler(aggregateFutureLogHandler);
    super.tearDown();
  }

  /*

        or even industries — utilities useful for a sizable proportion of all Java programmers
        everywhere. If you can give enough detail such that any of us can imagine coming across
        a similar need in our own work, that's extremely helpful in studying how broadly useful the
        feature will be.

  - type: textarea
    attributes:
      label: Concrete Use Cases

  @Override
  public void tearDown() throws Exception {
    /*
     * Clear interrupt for future tests.
     *
     * (Ideally we would perform interrupts only in threads that we create, but
     * it's hard to imagine that anything will break in practice.)
     */
    clearInterrupt();
    aggregateFutureLogger.removeHandler(aggregateFutureLogHandler);
    super.tearDown();
  }

  /*

    //     in all.
    // (3) "Successive". We can consider that we are exchanging a block of size d (a[0..d-1]) with a
    //     block of size n-d (a[d..n-1]), where in general these blocks have different sizes. If we
    //     imagine a line separating the first block from the second, we can proceed by exchanging
    //     the smaller of these blocks with the far end of the other one. That leaves us with a
    //     smaller version of the same problem.

 * finalized. If this object is garbage collected earlier, the backing thread will not invoke {@code
 * finalizeReferent()} on the remaining references.
 *
 * <p>As an example of how this is used, imagine you have a class {@code MyServer} that creates a
 * {@link java.net.ServerSocket ServerSocket}, and you would like to ensure that the {@code

 * finalized. If this object is garbage collected earlier, the backing thread will not invoke {@code
 * finalizeReferent()} on the remaining references.
 *
 * <p>As an example of how this is used, imagine you have a class {@code MyServer} that creates a
 * {@link java.net.ServerSocket ServerSocket}, and you would like to ensure that the {@code