public static synchronized String gen() {
 StringBuilder builder = new StringBuilder(System.nanoTime() / 1000 + "");
 if (SEQ.incrementAndGet() % 10 == 0) {
  SEQ.incrementAndGet();
 }
 builder.append(FORMAT.format(SEQ.get()));
 if ((MAX_PAD_SIZE - 1) == SEQ.get()) {
  SEQ.set(1);
 }
 long v = Long.parseLong(builder.reverse().toString());
 return Base62.encode(v);
}

这里用千分之一纳秒做基数（经测试，基数在10w分之一纳秒内都是安全的），再加上1~99的顺序号来生成唯一ID。最终可以保证在大于10纳秒（近似）的时间区间内不会产生重复值。

为了缩减长度，对字符串做了 Base62处理。在处理前又将纳秒数值做了一次翻转处理。不难想象，如果直接使用原始值来做Base62处理，因为时钟的特征，最终生成的值的前几位都是相同的。

来看一下这个程序生成的ID：

aSPog4cC
d4t1xZdt
g2tkZVqv
jrinwXx5
m8ZIAKVr
oUB5nzS5
rZa1gPAl
uD12VZ3A
8dnItkTj

八位的长度，唯一且整齐。下面是一个单元测试：

@Test
public void gen() {
 int size = 10240;
 Set set = new HashSet<>();
 for (int i = 0; i < size; i++) {
  String code = ShortCode.gen();
  //System.out.println(code);
  set.add(code);
 }
 Assert.assertEquals(size, set.size());
}

这里只对10240的规模做了测试。因为唯一ID是基于时钟生成的，所以测试时整体规模的大小不影响ID的唯一性（和短链接方案不一样）。但是太小了也不行——顺序号会发挥作用。10240算是一个中庸的值，足够暴露问题，也不会有太多的冗余。

仍然需要强调一下：这个方案只能保证在（当前）单机上的唯一性，如果是集群范围内建议采用其他方案，或者加上一两位机器ID。