抓到Dubbo非同步呼叫的小BUG，再送你一個貢獻開原始碼的機會

捉蟲大師發表於2022-07-04
非同步原始碼

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

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

image

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

image

問題復現

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

image

他的問題原話是：

今天發現一個問題 有一個dubbo介面返回型別是boolean， 把介面從同步改成非同步 server 端返回true 消費端卻返回false，把boolean改成Boolean就能正常返回結果 有碰到過這個問題嗎

注意幾個重點：

  • 介面返回型別是boolean
  • 同步改為非同步呼叫返回的boolean和預期不符合
  • boolean基本型別改成包裝型別Boolean就能正常返回

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

《Java開發手冊》中就強調了RPC介面返回最好不要使用基本型別，而要使用包裝型別：

image

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

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

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

哎，等等~

Dubbo非同步呼叫的寫法可多了，於是我又問了下他是怎麼寫的。

image

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

  1. 定義Dubbo介面，一個返回boolean，一個返回Boolean
public interface DemoService {
    boolean isUser();
    Boolean isFood();
}
  1. 實現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;
    }
}
  1. 實現Consumer，為了方便呼叫，實現了一個Controller，為了防止本機呼叫，injvm設定為false，這裡是經驗，injvm呼叫邏輯和遠端呼叫區別挺大，為了防止干擾，統一遠端呼叫。
@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";
    }
}
  1. 啟動一個Provider，再啟動一個Consumer進行測試，果然和提問的同學表現一致：
  • 先呼叫isUser（返回boolean），控制檯列印：
// client ...
client is user = false
// server ...
server is user : true
  • 再呼叫isFood（返回Boolean），控制檯列印：
// client ...
client is food = true
// server ...
server is food : true

問題排查

  1. Debug

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

如果你非常熟悉Dubbo的呼叫過程，直接知道大概在這裡

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

如果你不熟悉，那就比較困難了，推薦讀一下之前的文章《我是一個Dubbo資料包...》，知道得越多，幹活就越快。

我們打3個斷點：
image

image

  • 斷點①為了證明我們的請求進來了
  • 斷點②為了證明進了回撥
  • 斷點③為了能從接受到資料包的初始位置開始排查

按照我們的想法，執行順序應該是①、③、②，但是這裡很奇怪，並沒有按照我們的預期執行，而是先執行①，再執行②，最後執行③！

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

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

image

發現這裡callable呼叫call返回了false，然後false不為null且不是CompletableFuture的例項，於是直接呼叫了CompletableFuture.completedFuture(o)。

看到這裡估計有部分小夥伴發現了問題，正常情況下，Dubbo的非同步呼叫，執行呼叫後，不會立馬得到結果，只會拿到一個null或者一個CompletableFuture，然後在回撥方法中等待server端的返回。

這裡的邏輯是如果返回的結果不為null且不為CompletableFuture的例項就直接將CompletableFuture設定為完成，立馬執行回撥。

暫且不管這個邏輯。

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

  1. arthas

我們下載安裝一個arthas，可以參考如下文件：

https://arthas.aliyun.com/doc/quick-start.html

attach到我們的Consumer程式上，執行sc命令（檢視已載入的類）檢視所有生成的代理類，由於我們的Demo就生成了一個，所以看起來很清晰

sc *.proxy0

image

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

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

image

看到這裡估計小夥伴們又揭開了一層疑惑，this.handler.invoke就是去呼叫Provider，由於這裡是非同步呼叫，必然返回的是null，所以返回值定義為boolean的方法返回了false。

看到這裡，估計小夥伴們對《Java開發手冊》裡的規範有了更深的理解，這裡的處理成false也是無奈之舉，不然難道返回true？屬於資訊丟失了，無法區分是呼叫的返回還是其他異常情況。

我們再回頭看asyncCall：

image

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

從這個方法的名字能看出它是執行非同步呼叫，但這裡有行註釋：

//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，但沒有什麼發現，說明這個BUG遇到的人很少，可能是大家用非同步呼叫本來就很少，再加上返回基本型別就更少，所以也不奇怪。

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

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

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

最後，感謝群裡小夥伴提供素材，感謝大家的閱讀，如果能動動小手幫我點個贊和在看就更好了。我們下期再見~

對了，標題為什麼叫《再送你一次》？因為之前送過呀~

  • 本文已收錄 https://github.com/lkxiaolou/lkxiaolou 歡迎star。
  • 搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。

相關文章