android Jni AttachCurrentThread 内存泄露

说起这个问题来就牛逼大了，俺弄了差不多两天才定位到。

 

jni内存泄露定位起来真特么麻烦，受不鸟

 

现象

先说一下结果吧，我是做在线视频应用的，数据得由C往Java层抛。俺在测试的时候发现拿一台机器跑几个小时候就木有内存了，报如下错误：

07-10 19:31:46.871: E/dalvikvm-heap(3756): Out of memory on a 126-byte allocation.
07-10 19:31:46.871: I/dalvikvm(3756): Can't dump thread 5041: threadObj not set
07-10 19:31:46.871: E/dalvikvm(3756): Out of memory: Heap Size=32775KB, Allocated=29914KB, Bitmap Size=0KB, Limit=32768KB
07-10 19:31:46.871: E/dalvikvm(3756): Extra info: Footprint=32711KB, Allowed Footprint=32775KB, Trimmed=468KB
07-10 19:31:46.871: W/dalvikvm(3756): Could not allocate message string "(null)" while throwing internal exception (Ljava/lang/OutOfMemoryError;)

 

然后哥就各种定位啊，你想啊，肯定不是视频数据的内存泄露，一来我使用了复用的内存块，二来如果是视频数据泄露，每一帧数据都有640*480这么大，跑一会儿就挂了，根本跑不了几小时。然后哥哥就各种查啊，吐槽一下MAT真特么难用，怎么就不学学人家Xcode上的instruments呢，反正我是分析半天没结果，后来各种注释代码之后，发现是jni层的问题。好了，最后发现居然是AttachCurrentThread这货的问题，尼玛，坑爹啊，这分明是Bug嘛。

 

按理来说，每次从C往Java抛数据都得这么干(我就写个大概意思就好了)

void paoshuju(char* buf, int size)

{

     AttachCurrentThread

     //在这儿copy内存啊之类的

     //DetachCurrentThread

}

哥哥真的是这么干的呀，然后内存就华丽丽的泄露了，擦，真的是Bug

 

解决办法

好吧，我就搞个全局变量嘛，每个线程只AttachCurrentThread一次，存储env作为全局变量，然后线程结束的时候回来DetachCurrentThread

这样这个问题就解决了。

但是这样解决的后遗症就是必须得对每个接口调用的线程非常清楚，否则程序就会crash