非常典型，但是又非常容易出错的地方

场景：团队内造了一个轮子，即使用Redis实现分布式锁。

//加锁
public boolean tryAcquire(String key,long expireTime);
//释放锁
public boolean release(String key);

业务代码：

public void consume(){
  if(tryAcquire(key,30)){
    try{
      //业务逻辑，调用接口全量的拉取数据
    }finally{
      release(key);
    }
  }
}

然后上线后，CPU飙升。

详细的排查过程可以参考下文：

JVM那点事-JDK命令行工具+JProfiler的使用（排查线上问题）
JVM那点事—show-busy-java-threads排查CPU性能问题

问题定位到就是

• GC线程数量上升，导致CPU利用率飙升。
• 日志出现的是tryAcquire操作无效，大量线程并发的调用接口拉取全量数据；

最终定位的原因就是：tryAcquire中的expireTime单位是ms，而开发的同学以为这个单位是秒，以为设置30s的超时时间，造成了一次生产事故。

得到的教训是：方法的参数命名要规范，不能给人一种很模糊的感觉；