栈内存溢出-StackOverflowError

下面test方法是一个死循环自己调自己的例子。运行这个方法，你会看到熟悉又不常见的java.lang.StackOverflowError（栈内存溢出错误）：

package com.clz;

import org.junit.Test;

public class TestMain {
    @Test
    public void testStackOverflowError() {
        testStackOverflowError();
    }

}

运行结果：

java.lang.StackOverflowError
    at com.clz.TestMain.testStackOverflowError(TestMain.java:8)--（第1条stackTrace）
    at com.clz.TestMain.testStackOverflowError(TestMain.java:8)--（第2条stackTrace）
    at com.clz.TestMain.testStackOverflowError(TestMain.java:8)--（第3条stackTrace）
    。。。。。。
    at com.clz.TestMain.testStackOverflowError(TestMain.java:8)--（第500条stackTrace）
    。。。。。。
    at com.clz.TestMain.testStackOverflowError(TestMain.java:8)--（第1022条stackTrace）
    at com.clz.TestMain.testStackOverflowError(TestMain.java:8)--（第1023条stackTrace）
    at com.clz.TestMain.testStackOverflowError(TestMain.java:8)--（第1024条stackTrace）

注意到以上运行结果，一共会打印出来1024条stacktrace信息。说明java中线程栈的长度是1024。

------------我是么么哒分割线----------------

线程栈：thread stack。我们分析程序的jvm dump时，往往需要通过查看Thread Stack来分析问题。比如下图：

------------我是么么哒分割线----------------

java.lang.StackOverflowError栈内存溢出是进行复杂运算时非常容易出现的错误。

我们来看如下代码的线程栈图示

public class Demo {
    public static void main(String[] args) {
        String message="hello JVisualVM world";
        hello(message);
    }

    private static void hello(String text) {
        System.out.println(text);
    }
}

在java中，虚拟机会为每个任务的处理分配一个线程， 在这个线程里，每次调用一个方法，都会将本次方法调用的栈桢压入虚拟机栈里，这个栈桢里保存着方法内部的局部变量和其他信息。 不过呢，每个线程的虚拟机栈的大小是固定的，默认为1MB（上面的1024）。

既然一个线程的虚拟机栈内存大小是有限的，那么假设不停的调用各种方法，对应的栈桢不停的压入栈中。当这些大量的栈桢消耗完毕这个1MB的线程栈内存，最终就会导致出现栈内存溢出的情况。

------------我是么么哒分割线----------------

而我在上周四boss开工改版时，对redis分布式锁接口方法做了调整，却因为一个失误导致了StackOverflowError。

>>先看接口定义，然后再说问题：

package com.emax.zhenghe.common.concurrent.distributeRedisLock;

public interface DistributedLock {
        
     boolean lock(String key);
    
     boolean lock(String key, int retryTimes);
    
     boolean lock(String key, int retryTimes, long sleepMillis);
    
     boolean lock(String key, long expireMillis);
    
     boolean lock(String key, long expireMillis, int retryTimes);
    
     boolean lock(String key, long expireMillis, int retryTimes, long sleepMillis);
    
     boolean releaseLock(String key);
}

>>接下来说问题：

分布式锁在技术层面有两种应用场景：
1. 可以保证幂等性（防重与幂等有区别：幂等通常是对并发请求的防重控制；防重除了需要分布式保证幂等以外，还需要做数据防重校验，因为重复请求可能不是并发请求过来的，有可能是隔了很长时间的重复数据提交，就是用DCL）
2. 实现进程同步（类似于线程synchronized锁）：当锁存在时，需要不断尝试重试取锁，实现自旋等待。

这个接口正好也为两种应用场景定义了方法API。问题在于，我们看这些lock重载方法，比较第7行的lock(String,int)与第11行的lock(String,long)，再比较第9行的lock(String,int,long)与第13行的lock(String,long,int)，太容易误用了。事实也证明了这一点，项目的业务代码里有很多用来保证幂等性的逻辑调用的是lock(String,int)或lock(String,long,int)，而非lock(String,long)，那么，显然无法达到幂等控制的效果。

为了解决项目中现存的这种误用，并规避日后的误用，有必要重构这个接口。如下是第一版：

package com.emax.zhenghe.common.concurrent.distributeRedisLock;

public interface DistributedLock {
    boolean lock(String key);

//     boolean lock(String key, int retryTimes);

//    boolean lock(String key, int retryTimes, long sleepMillis);
//     boolean synchronize(String key, int retryTimes, long sleepMillis);

    boolean lock(String key, long expireMillis);

    /**
     * 注：有很多项目很多代码调用了这个方法，过渡阶段先保留这个方法api
     * 注：此方法不再使用。请不要使用过期的方法
     * @param key
     * @param expireMillis
     * @param useless 有很多地方在用，不得不定义这个寂寞参数
     * @return
     */
    @Deprecated
    default boolean lock(String key, long expireMillis,int useless){
        return lock(key, expireMillis, 0);
    }

    //    boolean lock(String key, long expireMillis, int retryTimes);
    boolean synchronize(String key, long expireMillis, int retryTimes);

    //    boolean lock(String key, long expireMillis, int retryTimes, long sleepMillis);
    boolean synchronize(String key, long expireMillis, int retryTimes, long sleepMillis);

    boolean releaseLock(String key);

    boolean releaseLockUnsafe(String key);
}

导致出现StackOverflowError的，正是第22行标记了过时的lock(String key, long expireMillis,int useless)。这个方法调用的是其自身！而我的本意是要它调用第11行的lock(key, expireMillis)：

。。。
13     /**
14      * 注：有很多项目很多代码调用了这个方法，过渡阶段先保留这个方法api
15      * 注：此方法不再使用。请不要使用过期的方法
16      * @param key
17      * @param expireMillis
18      * @param useless 有很多地方在用，不得不定义这个寂寞参数
19      * @return
20      */
21     @Deprecated
22     default boolean lock(String key, long expireMillis,int useless){
23         return lock(key, expireMillis);
24     }
。。。