问题描述
国庆后正式辞职了，在交接完成前，也就摸摸鱼或者帮同事分析一些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 测试就没有出现该问题，应该是解决了。
