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

最近一個技術(shù)群有同學(xué)at我，問我是否熟悉Dubbo，這我熟啊~

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

問題復(fù)現(xiàn)

遇到問題，尤其不是自己遇到的，必須要復(fù)現(xiàn)出來才好排查，截一個當(dāng)時的聊天記錄：

他的問題原話是：

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

注意幾個重點：

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

聽到這個描述，我的第一反應(yīng)是這個返回結(jié)果定義為boolean肯定有問題！

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

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

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

于是我拉了個工程準(zhǔn)備復(fù)現(xiàn)這個問題。

哎，等等~

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

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

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

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

實現(xiàn)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;
    }
}

實現(xiàn)Consumer，為了方便調(diào)用，實現(xiàn)了一個Controller，為了防止本機調(diào)用，injvm設(shè)置為false，這里是經(jīng)驗，injvm調(diào)用邏輯和遠(yuǎn)程調(diào)用區(qū)別挺大，為了防止干擾，統(tǒng)一遠(yuǎn)程調(diào)用。

@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進行測試，果然和提問的同學(xué)表現(xiàn)一致：

• 先調(diào)用isUser（返回boolean），控制臺打印：

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

• 再調(diào)用isFood（返回Boolean），控制臺打印：

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

問題排查

• Debug

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

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

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

我們打3個斷點：

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

斷點②為了證明進了回調(diào)

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

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

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

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

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

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

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

暫且不管這個邏輯。

我們先看為什么會返回false。這里的callable是Dubbo生成的一個代理類，其實就是封裝了調(diào)用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就是去調(diào)用Provider，由于這里是異步調(diào)用，必然返回的是null，所以返回值定義為boolean的方法返回了false。

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

我們再回頭看asyncCall：

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

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

//local invoke will return directly

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

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

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

server is user : true
client is user = true

如何修復(fù)

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

修復(fù)的辦法就是在injvm分支這里加上判斷，如果是injvm調(diào)用還是保持現(xiàn)狀，如果不是injvm調(diào)用，直接忽略，走最后的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ā)現(xiàn)，說明這個BUG遇到的人很少，可能是大家用異步調(diào)用本來就很少，再加上返回基本類型就更少，所以也不奇怪。

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

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

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