hello，大家好呀，我是小樓。

最近一個技術群有同學at我，問我是否熟悉Dubbo，這我熟啊~

他說遇到了一個Dubbo異步調用的問題，懷疑是個BUG，提到BUG我可就不困了，說不定可以水，哦不...寫一篇文章。

問題復現

遇到問題，尤其不是自己遇到的，必須要復現出來才好排查，截一個當時的聊天記錄：

他的問題原話是：

今天發(fā)現一個問題 有一個dubbo接口返回類型是boolean， 把接口從同步改成異步 server 端返回true 消費端卻返回false，把boolean改成Boolean就能正常返回結果 有碰到過這個問題嗎

注意幾個重點：

• 接口返回類型是boolean
• 同步改為異步調用返回的boolean和預期不符合
• boolean基本類型改成包裝類型Boolean就能正常返回

聽到這個描述，我的第一反應是這個返回結果定義為boolean肯定有問題！

《Java開發(fā)手冊》中就強調了RPC接口返回最好不要使用基本類型，而要使用包裝類型：

但這個是業(yè)務編碼規(guī)范，如果RPC框架不能使用boolean作為返回值，豈不是個BUG？而且他強調了是同步改為異步調用才出現這種情況，說明同步沒問題，有可能是異步調用的鍋。

于是我順口問了Dubbo的版本，說不定是某個版本的BUG。得到回復，是2.7.4版本的Dubbo。

于是我拉了個工程準備復現這個問題。

哎，等等~

Dubbo異步調用的寫法可多了，于是我又問了下他是怎么寫的。

知道怎么寫的就好辦了，寫個Demo先：

定義Dubbo接口，一個返回boolean，一個返回Boolean

public interface DemoService {
    boolean isUser();
    Boolean isFood();
}

實現Provider，為了簡單，都返回true，并且打了日志

@Service
public class DemoServiceImpl implements DemoService {

    @Override
    public boolean isUser() {
        System.out.println("server is user : true");
        return true;
    }

    @Override
    public Boolean isFood() {
        System.out.println("server is food : true");
        return true;
    }
}

實現Consumer，為了方便調用，實現了一個Controller，為了防止本機調用，injvm設置為false，這里是經驗，injvm調用邏輯和遠程調用區(qū)別挺大，為了防止干擾，統一遠程調用。

@RestController
public class DemoCallerService {

    @Reference(injvm = false, check = false)
    private DemoService demoService;

    @GetMapping(path = "/isUser")
    public String isUser() throws Exception {
        BlockingQueue<Boolean> q = new ArrayBlockingQueue<>(1);
        RpcContext.getContext().asyncCall(
                () -> demoService.isUser()
        ).handle(
                (isUser, throwable) -> {
                    System.out.println("client is user = " + isUser);
                    q.add(isUser);
                    return isUser;
                });
        q.take();
        return "ok";
    }

    @GetMapping(path = "/isFood")
    public String isFood() throws Exception {
        BlockingQueue<Boolean> q = new ArrayBlockingQueue<>(1);
        RpcContext.getContext().asyncCall(
                () -> demoService.isFood()
        ).handle(
                (isFood, throwable) -> {
                    System.out.println("client is food = " + isFood);
                    q.add(isFood);
                    return isFood;
                });
        q.take();
        return "ok";
    }
}

啟動一個Provider，再啟動一個Consumer進行測試，果然和提問的同學表現一致：

• 先調用isUser（返回boolean），控制臺打印：

// client ...
client is user = false
// server ...
server is user : true

• 再調用isFood（返回Boolean），控制臺打?。?/li>

// client ...
client is food = true
// server ...
server is food : true

問題排查

• Debug

先猜測一下是哪里的問題，server端返回true，應該問題不大，可能是client端哪里轉換出錯了。但這都是猜想，我們直接從client端接收到的數據開始，如果接收的數據沒問題，肯定就是后續(xù)處理出了點小差錯。

如果你非常熟悉Dubbo的調用過程，直接知道大概在這里

com.alibaba.dubbo.remoting.exchange.support.DefaultFuture#doReceived

我們打3個斷點：

斷點①為了證明我們的請求進來了

斷點②為了證明進了回調

斷點③為了能從接收到數據包的初始位置開始排查

按照我們的想法，執(zhí)行順序應該是①、③、②，但是這里很奇怪，并沒有按照我們的預期執(zhí)行，而是先執(zhí)行①，再執(zhí)行②，最后執(zhí)行③！

這是為什么？對于排查問題中的這些沒有符合預期的蛛絲馬跡，要特別留心，很可能就是一個突破點。

于是我們對asyncCall這個方法進行跟蹤：

發(fā)現這里callable調用call返回了false，然后false不為null且不是CompletableFuture的實例，于是直接調用了CompletableFuture.completedFuture(o)。

看到這里估計有部分小伙伴發(fā)現了問題，正常情況下，Dubbo的異步調用，執(zhí)行調用后，不會立馬得到結果，只會拿到一個null或者一個CompletableFuture，然后在回調方法中等待server端的返回。

這里的邏輯是如果返回的結果不為null且不為CompletableFuture的實例就直接將CompletableFuture設置為完成，立馬執(zhí)行回調。

暫且不管這個邏輯。

我們先看為什么會返回false。這里的callable是Dubbo生成的一個代理類，其實就是封裝了調用Provider的邏輯，有沒有辦法看看他封裝的邏輯呢？有！用arthas。

• arthas

我們下載安裝一個arthas，可以參考如下文檔：https://arthas.aliyun.com/doc/quick-start.html

attach到我們的Consumer進程上，執(zhí)行sc命令（查看已加載的類）查看所有生成的代理類，由于我們的Demo就生成了一個，所以看起來很清晰

sc *.proxy0

再使用jad命令反編譯已加載的類：

jad org.apache.dubbo.common.bytecode.proxy0

看到這里估計小伙伴們又揭開了一層疑惑，this.handler.invoke就是去調用Provider，由于這里是異步調用，必然返回的是null，所以返回值定義為boolean的方法返回了false。

看到這里，估計小伙伴們對《Java開發(fā)手冊》里的規(guī)范有了更深的理解，這里的處理成false也是無奈之舉，不然難道返回true？屬于信息丟失了，無法區(qū)分是調用的返回還是其他異常情況。

我們再回頭看asyncCall：

圈出來的這段代碼令人深思，尤其是最后一行，為啥直接將CompletableFuture設置為完成？

從這個方法的名字能看出它是執(zhí)行異步調用，但這里有行注釋：

//local invoke will return directly

首先這個注釋的格式上下不一，//之后講道理是需要一個空格的，我覺得這里提個PR改下代碼格式肯定能被接受~

其次local invoke，我理解應該是injvm這種調用，為啥要特殊處理？這個處理直接就導致了返回基本類型的接口在異步調用時必然會返回false的BUG。

我們測試一下injvm的調用，將demo中injvm參數改為true，Consumer和Provider都在一個進程中，果然和注釋說的一樣：

server is user : true
client is user = true

如何修復

我覺得這應該算是Dubbo的一個BUG，雖然這種寫法不提倡，但作為一款RPC框架，這個錯誤還是不應該。

修復的辦法就是在injvm分支這里加上判斷，如果是injvm調用還是保持現狀，如果不是injvm調用，直接忽略，走最后的return邏輯：

public <T> CompletableFuture<T> asyncCall(Callable<T> callable) {
    try {
        try {
            setAttachment(ASYNC_KEY, Boolean.TRUE.toString());
            final T o = callable.call();
            //local invoke will return directly
            if (o != null) {
                if (o instanceof CompletableFuture) {
                    return (CompletableFuture<T>) o;
                }
                if (injvm()) { // 偽代碼
                    return CompletableFuture.completedFuture(o);
                }
            } else {
                // The service has a normal sync method signature, should get future from RpcContext.
            }
        } catch (Exception e) {
            throw new RpcException(e);
        } finally {
            removeAttachment(ASYNC_KEY);
        }
    } catch (final RpcException e) {
        // ....
    }
    return ((CompletableFuture<T>) getContext().getFuture());
}

最后

排查過程中還搜索了github，但沒有什么發(fā)現，說明這個BUG遇到的人很少，可能是大家用異步調用本來就很少，再加上返回基本類型就更少，所以也不奇怪。

而且最新的代碼這個BUG也還存在，所以你懂我意思吧？這也是個提交PR的好機會~

不過話說回來，我們寫代碼最好還是要遵循規(guī)范，這些都是前人為我們總結的最佳實踐，如果不按規(guī)范來，可能就會有意想不到的問題。

當然遇到問題也不要慌，代碼就在那躺著，工具也多，還怕搞不定嗎？