* This test creates a long random sequence of inputs, then a lot of differently configured sinks
   * process it; all should produce the same answer, the only difference should be the number of
   * process()/processRemaining() invocations, due to alignment.
   */
  @AndroidIncompatible // slow. TODO(cpovirk): Maybe just reduce iterations under Android.
  public void testExhaustive() throws Exception {

    private DataIndexHelper dataIndexHelper;

    @Override
    public void setUp() throws Exception {
        super.setUp();
        dataIndexHelper = new DataIndexHelper();
        setupMockComponents();
        // Reduce default interval to minimize test execution time
        dataIndexHelper.setCrawlingExecutionInterval(1L); // 1ms instead of 5000ms
    }

    private void setupMockComponents() {

   * Nearly all declarations in this class are package-private,
   * accessed directly by subclasses.
   *
   * Table entries are of class Cell; a variant of AtomicLong padded
   * to reduce cache contention on most processors. Padding is
   * overkill for most Atomics because they are usually irregularly
   * scattered in memory and thus don't interfere much with each

   * following conditions:
   *
   * <ul>
   *   <li>You want to assign the same fraction of inputs to each bucket.
   *   <li>When you reduce the number of buckets, you can accept that the most recently added
   *       buckets will be removed first. More concretely, if you are dividing traffic among tasks,

 *       hand, is multiple-use, and does implement {@link Iterable}.
 *   <li>Streams offer many features not found here, including {@code min/max}, {@code distinct},
 *       {@code reduce}, {@code sorted}, the very powerful {@code collect}, and built-in support for
 *       parallelizing stream operations.
 *   <li>{@code FluentIterable} contains several features not available on {@code Stream}, which are

 *       hand, is multiple-use, and does implement {@link Iterable}.
 *   <li>Streams offer many features not found here, including {@code min/max}, {@code distinct},
 *       {@code reduce}, {@code sorted}, the very powerful {@code collect}, and built-in support for
 *       parallelizing stream operations.
 *   <li>{@code FluentIterable} contains several features not available on {@code Stream}, which are

                .filter(q -> StringUtil.isNotBlank(q) && q.length() <= maxQueryLength)
                .forEach(oq -> split(oq, " ")
                        .get(s -> s.filter(StringUtil::isNotBlank).reduce((q1, q2) -> escape(q1, "(", ")") + OR + escape(q2, "(", ")")))
                        .ifPresent(q -> {
                            appendQuery(queryBuf, q);
                        })));

   * following conditions:
   *
   * <ul>
   *   <li>You want to assign the same fraction of inputs to each bucket.
   *   <li>When you reduce the number of buckets, you can accept that the most recently added
   *       buckets will be removed first. More concretely, if you are dividing traffic among tasks,

    HashTestUtils.assertInvariants(Hashing.fingerprint2011());
    assertEquals("Hashing.fingerprint2011()", Hashing.fingerprint2011().toString());
  }

  @AndroidIncompatible // slow TODO(cpovirk): Maybe just reduce iterations under Android.
  public void testGoodFastHash() {
    for (int i = 1; i < 200; i += 17) {
      HashFunction hasher = Hashing.goodFastHash(i);
      assertTrue(hasher.bits() >= i);

    @SuppressWarnings("SynchronizeOnNonFinalField")
    public T get() {
      // Another variant of Double Checked Locking.
      //
      // We use two volatile reads. We could reduce this to one by
      // putting our fields into a holder class, but (at least on x86)
      // the extra memory consumption and indirection are more
      // expensive than the extra volatile reads.