BinderProxy 泄露导致的 Crash

问题描述

国庆后正式辞职了，在交接完成前，也就摸摸鱼或者帮同事分析一些Jira上严重的bug，同事负责的车载项目已经进行小批量试产，Monkey 测试的强度也开始提高，然后不出意外的话是要出意外了，一个车辆核心功能的 service 在高强度的 monkey 测试中几乎必挂。

出问题的 service 负责车辆『数据埋点』通信的业务，车机中几十个应用和服务都需要经过这个 service 来向 『T-box』 汇报埋点数据，IPC 通信方式使用经典的 AIDL 实现。

完整的日志如下：

01-01 13:36:45.936     0     0 I binder  : release 1684:1718 transaction 57988729 in, still active
01-01 13:36:45.936     0     0 I binder  : send failed reply for transaction 57988729 to 3135:3254
09-30 21:53:02.514  1684  1718 E AndroidRuntime: FATAL EXCEPTION: Binder:1684_2
09-30 21:53:02.514  1684  1718 E AndroidRuntime: Process: com.xxx.xxx.xxxservice, PID: 1684
09-30 21:53:02.514  1684  1718 E AndroidRuntime: java.lang.AssertionError: Binder ProxyMap has too many entries: 20691 (total), 20691 (uncleared), 20691 (uncleared after GC). BinderProxy leak?
09-30 21:53:02.514  1684  1718 E AndroidRuntime:         at android.os.BinderProxy$ProxyMap.set(BinderProxy.java:230)
09-30 21:53:02.514  1684  1718 E AndroidRuntime:         at android.os.BinderProxy.getInstance(BinderProxy.java:432)
09-30 21:53:02.514  1684  1718 E AndroidRuntime:         at android.os.Parcel.nativeReadStrongBinder(Native Method)
09-30 21:53:02.514  1684  1718 E AndroidRuntime:         at android.os.Parcel.readStrongBinder(Parcel.java:2483)
09-30 21:53:02.514  1684  1718 E AndroidRuntime:         at com.xxx.xxx.xxxservice.diagnostics.IDiagnosticsEvent$Stub.onTransact(IDiagnosticsEvent.java:121)
09-30 21:53:02.514  1684  1718 E AndroidRuntime:         at android.os.Binder.execTransactInternal(Binder.java:1154)
09-30 21:53:02.514  1684  1718 E AndroidRuntime:         at android.os.Binder.execTransact(Binder.java:1123)
09-30 21:53:02.221   754   754 I chatty  : uid=1000(system) Binder:754_3 identical 1 line
09-30 21:53:02.222   754   754 D NotificationService: 0|com.xxx.xxx.persontime|124|null|1000: updating permissions
09-30 21:53:02.521   754  4583 I DropBoxManagerService: add tag=system_app_crash isTagEnabled=true flags=0x2
09-30 21:53:02.523   754   962 I PackageWatchdog: Updated health check state for package com.xxx.xxx.xxxservice: INACTIVE -> INACTIVE
09-30 21:53:02.524   754  3061 W ActivityManager: Force-killing crashed app com.xxx.xxx.xxxservice at watcher's request
09-30 21:53:02.526  1684  1718 I Process : Sending signal. PID: 1684 SIG: 9

原因分析

问题从日志上看很明显了， Binder 也就是跨进程通信模块产生了内存泄露

java.lang.AssertionError: Binder ProxyMap has too many entries: 20691 (total), 20691 (uncleared), 20691 (uncleared after GC ). BinderProxy leak?

然后 linux 内核发送 signal=9 信号，系统主动杀死了该进程

Linux 信号也是一个非常有用的日志分析入口，有时候进程没有任何产生crash也被内核杀死的话，就可以考虑分析是不是收到了 Linux 的信号，再逐步往上推，往往会有意想不到的收获

09-30 21:53:02.526  1684  1718 I Process : Sending signal. PID: 1684 SIG: 9

继续看日志，可以发现实际触发binder泄露的代码在IDiagnosticsEvent.class的第121行

 AndroidRuntime:         at com.xxx.xxx.xxxservice.diagnostics.IDiagnosticsEvent$Stub.onTransact(IDiagnosticsEvent.java:121)

IDiagnosticsEvent.java是AIDL接口编译后产生的一个临时类，它的位置是：

工程MODULE/build/generated/aidl_source_output_dir/debug/out/com/xxx/xxx/xxxservice/xxx/

case  TRANSACTION_setSendListener:
{
  data.enforceInterface(descriptor);
  com.xxx.xxx.xxxservice.diagnostics.ISendEventListener _arg0;
_arg0 = com.xxx.xxx.xxxservice.diagnostics.ISendEventListener.Stub. asInterface (data.readStrongBinder());
  com.xxx.xxx.xxxservice.diagnostics.IDiagnosticsEvent _result = this.setSendListener(_arg0);
  reply.writeNoException();
  reply.writeStrongBinder((((_result!=null))?(_result.asBinder()):(null)));
  return  true;
}

第121行是 _arg0 = com.xxx.xxx.xxxservice.diagnostics.ISendEventListener.Stub. asInterface (data.readStrongBinder()); 也就是ISendEventListener这个类没有得到释放，那么就需要去代码中看setSendListener()这方法做了什么

在代码中setSendListener()是DiagnosticsEvent.class的一个成员方法，DiagnosticsEvent.class 本身也是一个Binder.Stub的逻辑实现类。

// DiagnosticsEvent
@Override
public IDiagnosticsEvent setSendListener(ISendEventListener listener) throws RemoteException {
    mListener = listener;
    mEvent.SetCallback(new DiagnosticsListener());
    return  this;
}

然后我们看一下 DiagnosticsListener.class这个类。

结果问题就出在这个在类中，DiagnosticListener也是一个Binder.Stub的实现类，但是作为内部类它持有了对外部类引用ISendEventListener。

到这里问题就已经很清晰了，是一个典型的内部类持有外部类的引用导致的内存泄露。

由于每次调用setSendListener()方法都会产生一个无法释放的DiagnosticsListener对象，久而久之就BinderProxy占用内存越来越大，最终导致进程被内核杀死。

private  class DiagnosticsListener extends ISendEventCallback.Stub {

    @Override
    public  void SendStatus(hal e) throws RemoteException {
        if (mListener != null) {
            EventInfos infos = new EventInfos();
            ...
            mListener.OnSendStatus(infos);
        }
    }
}

解决方案

既然知道了原因，那么修改就简单了：

1）内部类改为静态内部类，将对外部类的引用改为软引用

@Override
public IDiagnosticsEvent setSendListener(ISendEventListener listener) throws RemoteException {
    mEvent.SetCallback(new DiagnosticsListener(listener));
    return  this;
}

private  static  class DiagnosticsListener extends ISendEventCallback.Stub {

    private  final SoftReference<ISendEventListener> mSoftReference;

    public DiagnosticsListener(ISendEventListener listener) {
        mSoftReference = new SoftReference<>(listener);
    }

    @Override
    public  void SendStatus(t_hal e) throws RemoteException {
        ISendEventListener mListener = mSoftReference.get();
        if (mListener != null) {
            LogUtils.logD(TAG, "SendStatus" );
            EventInfos infos = new EventInfos();
            ...
            mListener.OnSendStatus(infos);
        }
    }
}

2）将内部类改为匿名内部类

匿名内部类不能绝对杜绝内存泄露，使用不当也会产生内存泄露

@Override
public IDiagnosticsEvent setSendListener(ISendEventListener listener) throws RemoteException {
    mEvent.SetCallback(new ISendEventCallback.Stub() {
        @Override
        public  void SendStatus(t_hal e) throws RemoteException {
            EventInfos infos = new EventInfos();
            ...
            listener.OnSendStatus(infos);
        }
    });
    return  this;
}

当然还有其它方法，比如把ISendEventCallback.Stub提前初始化成一个成员对象，而不是每次使用都去new等等。

问题排查完毕修改好代码后，再次执行 monkey 测试就没有出现该问题，应该是解决了。