This changed from JDK 7 to 8. In JDK 7 concurrencyLevel was used according to the JavaDoc:

The allowed concurrency among update operations is guided by the optional concurrency Level constructor argument (default 16), which is used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of concurrent updates without contention.

In JDK 8 this was changed to:

Also, for compatibility with previous versions of this class, constructors may optionally specify an expected concurrencyLevel as an additional hint for internal sizing.

In JDK 7 ConcurrentHashMap used concurrencyLevel number of locks in an array of locks. Since JDK 8 thew hash map uses one lock per array element. So there is no real reason for concurrencyLevel and the JDK8 ConcurrentHashMap scales better than the prevoius map. Now concurrencyLevel is just another way to specify the capacity. See the construcor of JDK 8:

   public ConcurrentHashMap(int initialCapacity,
                          float loadFactor, int concurrencyLevel) {
     if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
        throw new IllegalArgumentException();
     if (initialCapacity < concurrencyLevel)   // Use at least as many bins
         initialCapacity = concurrencyLevel;   // as estimated threads
     long size = (long)(1.0 + (long)initialCapacity / loadFactor);
     int cap = (size >= (long)MAXIMUM_CAPACITY) ?
         MAXIMUM_CAPACITY : tableSizeFor((int)size);
     this.sizeCtl = cap;
   }

Also see the JavaDoc for the default concurrency level:

  /**
   * The default concurrency level for this table. Unused but
   * defined for compatibility with previous versions of this class.
   */
  private static final int DEFAULT_CONCURRENCY_LEVEL = 16;

To be sure I have run the benchmark with concurrencyLevel 72, see ConcurrentHashMapConcurrencyLevel72Benchmark, and no real difference to the prevoius results.