assertEquals(1, pageList.size());
        assertEquals("1", pageList.get(0));
    }

    @Test
    public void test_calculatePageInfo_largePageRange() {
        // Test when we have more than 11 pages (pageRangeSize * 2 + 1)
        QueryResponseList qrList = new QueryResponseList(null, 50, 10, 0) {
            @Override
            public int size() {
                return 10;
            }

        for (int i = 0; i < sampleSize; i++) {
            nonces[i] = encryptionContext.generateNonce();
        }

        // Then - Check that counter portion has entropy
        // For SMB3-compliant nonces, the first 8 bytes are a counter (little-endian)
        // so we check that the counter bytes change as expected
        Set<String> uniqueCounters = new HashSet<>();
        for (int i = 0; i < sampleSize; i++) {

			accessKey:          credentials.AccessKey,
			secretKey:          credentials.SecretKey,
			expectedRespStatus: http.StatusNoContent,
		},
		// Test case - 2.
		// Setting the content length to be more than max allowed size.
		// Expecting StatusBadRequest (400).
		{
			bucketName:         bucketName,
			bucketPolicyReader: bytes.NewReader(fmt.Appendf(nil, bucketPolicyTemplate, bucketName, bucketName)),

		// This is necessary for users that need to do additional time
		// calculations when dealing with legacy ZIP formats.
		if f.ModifiedTime != 0 || f.ModifiedDate != 0 {
			f.Modified = modified.In(timeZone(msdosModified.Sub(modified)))
		}
	}

	// Assume that uncompressed size 2³²-1 could plausibly happen in
	// an old zip32 file that was sharding inputs into the largest chunks

      return name;
    }

    @Override
    public boolean equals(@Nullable Object other) {
      if (other instanceof Alphabet) {
        Alphabet that = (Alphabet) other;
        return this.ignoreCase == that.ignoreCase && Arrays.equals(this.chars, that.chars);
      }
      return false;
    }

    @Override
    public int hashCode() {
      return Arrays.hashCode(chars) + (ignoreCase ? 1231 : 1237);

### 동시성이 병렬성보다 더 나은가요? { #is-concurrency-better-than-parallelism }

아니요! 그게 이 이야기의 교훈은 아닙니다.

동시성은 병렬성과 다릅니다. 그리고 많은 기다림이 포함되는 **특정한** 시나리오에서는 더 낫습니다. 그 때문에 웹 애플리케이션 개발에서는 일반적으로 병렬성보다 훨씬 더 낫습니다. 하지만 모든 것에 해당하진 않습니다.

그래서 균형을 맞추기 위해, 다음의 짧은 이야기를 상상해보세요:

    Iterable<String> iterable = asList("foo", "bar");
    assertThat(Iterables.getLast(iterable, "qux")).isEqualTo("bar");
  }

  /**
   * {@link ArrayList} extension that forbids the use of {@link Collection#iterator} for tests that
   * need to prove that it isn't called.
   */
  private static class DiesOnIteratorArrayList extends ArrayList<String> {
    /**
     * @throws UnsupportedOperationException all the time
     */

你可以同時利用並行性和平行性，進一步提升效能，這比大多數已測試的 NodeJS 框架都更快，並且與 Go 語言相當，而 Go 是一種更接近 C 的編譯語言（[感謝 Starlette](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query&l=zijmkf-1)）。

### 並行比平行更好嗎？ { #is-concurrency-better-than-parallelism }

不是的！這不是故事的本意。

並行與平行不同。並行在某些 **特定** 的需要大量等待的情境下表現更好。正因如此，並行在 Web 應用程式開發中通常比平行更有優勢。但並不是所有情境都如此。

因此，為了平衡報導，想像下面這個短故事

> 你需要打掃一間又大又髒的房子。

*是的，這就是全部的故事。*

---

你可以同时拥有并行性和异步性，你可以获得比大多数经过测试的 NodeJS 框架更高的性能，并且与 Go 不相上下， Go 是一种更接近于 C 的编译语言（[全部归功于 Starlette](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query&l=zijmkf-1)）。

### 并发比并行好吗？ { #is-concurrency-better-than-parallelism }

不！这不是故事的本意。

并发不同于并行。而是在需要大量等待的特定场景下效果更好。因此，在 Web 应用程序开发中，它通常比并行要好得多，但这并不意味着全部。

因此，为了平衡这一点，想象一下下面的短篇故事：

> 你必须打扫一个又大又脏的房子。

*是的，这就是完整的故事。*

---

  public void testExplicit_withDuplicates() {
    assertThrows(IllegalArgumentException.class, () -> Ordering.explicit(1, 2, 3, 4, 2));
  }

  // A more limited test than the one that follows, but this one uses the
  // actual public API.
  @J2ktIncompatible // Ordering.arbitrary
  public void testArbitrary_withoutCollisions() {
    List<Object> list = new ArrayList<>();