要做一个文件存储的功能,将原来一个对象存储到文件中,然后在用的时候读出来。
为什么要文件存储?
不要问我为什么非要用文件巴拉巴拉,正好赶在这了。
不能放内存里啊,因为这个对象大的时候,算了一下,也有几十M你敢信?而且这个项目是n次开发,之前数据库封装的有问题,数据溢出,内存泄漏的,短时间内一定优化不了啊。
一,这代码不是我写的,虽然能懂,但细节问题仍需深扣。二,写这代码的人还活着吗都不知道了,有看不懂的地方。。。。。。谁也问不了,死看。三,这种优化类的需求需要长时间的观察,审核代码,才能优化。然而甲方的要求又是,速度和质量同求,呵呵,这个对于现在的我来说,真难。因为我菜。
本来就别人嫌我慢。。。那好,快自然有快的办法。。。
文件存储是现在唯一的最优解了。于是存储的时候发现一个挺搞笑的事。也怪我笑点低。
序列化存储的坑:
有一个类A,A中有一个字段List< B >,B中有一个字段A。
讲到这里,相信有人已经懂了。序列化存储的时候,这个玩意A会产生无穷大的结果,无论内存多大,都会占满,真的很好笑。尤其是你兴致勃勃写完代码之后,一运行,发现报内存溢出的错误,原来是不断的生成流不断的生成流,一直在生成,,,哈哈。
更好笑就在于,在Stack Overflow上,有人嘲笑此举乃白痴也:
https://stackoverflow.com/questions/27224175/stopped-service-is-doing-constant-garbage-collection
关键内容如下:
问题:
I am developing an application which has many services. When I stop the intent service, all threads and service should be stopped but the UI is hung and the following errors are in logcat:
2014-12-01 12: 37: 92I/art (32099): Background partial concurrent mark sweep GC freed 419756(33MB) AllocSpace objects, 15(4MB) LOS objects, 38% free, 25MB/41MB, paused 1.617ms total 451.976ms
2014-12-01 12: 37: 40I/art (32099): Background sticky concurrent mark sweep GC freed 290680(16MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 25MB/33MB, paused 23.287ms total 229.513ms
2014-12-01 12: 37: 29I/art (32099): Background partial concurrent mark sweep GC freed 165880(9MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 23MB/39MB, paused 1.648ms total 203.601ms
2014-12-01 12: 37: 54I/art (32099): Background sticky concurrent mark sweep GC freed 269770(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 2.533ms total 207.538ms
2014-12-01 12: 37: 54I/art (32099): WaitForGcToComplete blocked for 170.151ms for cause HeapTrim
2014-12-01 12: 37: 22I/art (32099): Background partial concurrent mark sweep GC freed 155347(8MB) AllocSpace objects, 0(0B) LOS objects, 40% free, 23MB/39MB, paused 1.464ms total 181.474ms
2014-12-01 12: 38: 45I/art (32099): Background sticky concurrent mark sweep GC freed 267766(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.556ms total 149.855ms
2014-12-01 12: 38: 11I/art (32099): Background sticky concurrent mark sweep GC freed 137696(7MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.617ms total 125.255ms
2014-12-01 12: 38: 82I/art (32099): Background partial concurrent mark sweep GC freed 148859(8MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 23MB/39MB, paused 1.373ms total 216.542ms
2014-12-01 12: 38: 11I/art (32099): Background sticky concurrent mark sweep GC freed 276636(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.403ms total 156.661ms
2014-12-01 12: 38: 97I/art (32099): Background sticky concurrent mark sweep GC freed 139573(7MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.464ms total 115.336ms
2014-12-01 12: 38: 85I/art (32099): Background partial concurrent mark sweep GC freed 151267(8MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 23MB/39MB, paused 2.227ms total 210.346ms
2014-12-01 12: 38: 44I/art (32099): Background sticky concurrent mark sweep GC freed 268102(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.495ms total 148.542ms
2014-12-01 12: 38: 27I/art (32099): Background sticky concurrent mark sweep GC freed 137761(7MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.587ms total 119.121ms
2014-12-01 12: 38: 26I/art (32099): Background partial concurrent mark sweep GC freed 154492(9MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 23MB/39MB, paused 2.533ms total 314.939ms
2014-12-01 12: 38: 75I/art (32099): Thread[5,tid=32108,WaitingInMainSignalCatcherLoop,Thread*=0xb8111d98,peer=0x12c07080,"Signal Catcher"]: reacting to signal 3
2014-12-01 12: 38: 79W/art (32099): Suspending all threads took: 13.062ms
2014-12-01 12: 38: 80I/art (32099): Wrote stack traces to '/data/anr/traces.txt'
2014-12-01 12: 38: 89I/art (32099): Background sticky concurrent mark sweep GC freed 278516(15MB) AllocSpace objects, 0(0B) LOS objects, 25% free, 23MB/31MB, paused 2.533ms total 1.049s
2014-12-01 12: 38: 13I/art (32099): Background partial concurrent mark sweep GC freed 137132(8MB) AllocSpace objects, 0(0B) LOS objects, 40% free, 23MB/39MB, paused 4.211ms total 188.951ms
2014-12-01 12: 38: 42I/art (32099): Background sticky concurrent mark sweep GC freed 271335(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 3.998ms total 236.868ms
2014-12-01 12: 38: 41I/art (32099): Background sticky concurrent mark sweep GC freed 143812(8MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 24MB/32MB, paused 6.470ms total 201.800ms
2014-12-01 12: 38: 36I/art (32099): Background partial concurrent mark sweep GC freed 159223(9MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 23MB/39MB, paused 5.524ms total 215.809ms
2014-12-01 12: 38: 61I/art (32099): Background sticky concurrent mark sweep GC freed 278158(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.922ms total 201.617ms
2014-12-01 12: 38: 41I/art (32099): WaitForGcToComplete blocked for 46.696ms for cause HeapTrim
2014-12-01 12: 38: 79I/art (32099): Background sticky concurrent mark sweep GC freed 136821(7MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 24MB/32MB, paused 1.709ms total 123.729ms
2014-12-01 12: 38: 30I/art (32099): Background sticky concurrent mark sweep GC freed 116947(6MB) AllocSpace objects, 0(0B) LOS objects, 20% free, 25MB/32MB, paused 5.554ms total 138.501ms
2014-12-01 12: 38: 44I/art (32099): Background sticky concurrent mark sweep GC freed 117175(6MB) AllocSpace objects, 0(0B) LOS objects, 19% free, 25MB/32MB, paused 1.678ms total 104.257ms
2014-12-01 12: 38: 19I/art (32099): Background sticky concurrent mark sweep GC freed 110760(6MB) AllocSpace objects, 0(0B) LOS objects, 18% free, 26MB/32MB, paused 1.587ms total 104.959ms
2014-12-01 12: 39: 37I/art (32099): Background sticky concurrent mark sweep GC freed 88168(4MB) AllocSpace objects, 0(0B) LOS objects, 15% free, 27MB/32MB, paused 3.876ms total 114.878ms
2014-12-01 12: 39: 54I/art (32099): Background partial concurrent mark sweep GC freed 136364(8MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 23MB/39MB, paused 1.648ms total 102.212ms
2014-12-01 12: 39: 60I/art (32099): Background sticky concurrent mark sweep GC freed 287788(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 3.418ms total 196.154ms
2014-12-01 12: 39: 80I/art (32099): Background sticky concurrent mark sweep GC freed 156308(8MB) AllocSpace objects, 0(0B) LOS objects, 25% free, 23MB/31MB, paused 3.998ms total 184.495ms
2014-12-01 12: 39: 33I/art (32099): Background partial concurrent mark sweep GC freed 148206(8MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 23MB/39MB, paused 1.831ms total 103.738ms
2014-12-01 12: 39: 59I/art (32099): Background sticky concurrent mark sweep GC freed 283901(15MB) AllocSpace objects, 0(0B) LOS objects, 25% free, 23MB/31MB, paused 2.502ms total 144.086ms
2014-12-01 12: 39: 43I/art (32099): Background sticky concurrent mark sweep GC freed 134828(7MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/31MB, paused 2.533ms total 130.291ms
2014-12-01 12: 39: 44I/art (32099): WaitForGcToComplete blocked for 94.277ms for cause HeapTrim
2014-12-01 12: 39: 95I/art (32099): Background sticky concurrent mark sweep GC freed 133441(7MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 24MB/31MB, paused 5.035ms total 139.722ms
2014-12-01 12: 39: 47I/art (32099): Background partial concurrent mark sweep GC freed 148395(8MB) AllocSpace objects, 0(0B) LOS objects, 40% free, 23MB/39MB, paused 2.227ms total 122.722ms
2014-12-01 12: 39: 79I/art (32099): Background sticky concurrent mark sweep GC freed 280706(15MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 1.495ms total 175.156ms
2014-12-01 12: 39: 44I/art (32099): Background sticky concurrent mark sweep GC freed 144094(8MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 24MB/32MB, paused 2.258ms total 140.119ms
回答:
I had the same issue and discovered that it was due to a circular reference problem when serializing an object to JSON, using Gson library. Generated JSON was infinite, and memory isn’t, so app stalled. I know it sounds idiot, but it’s true, :-) – German Latorre Feb 16 ‘15 at 10:05
那人问:
我开发一个应用的时候,有许多的服务,当我关闭启动式服务的时候,所有的线程和服务都应该关闭,但是UI仍然在停留着,并且在logcat上报了如下错误:
错误的内容就是说jvm可用内存满了之类。
然后一个回答:
他说他也有同样的问题,这是因为循环引用一个对象的问题,他在使用gson库时,序列化这个对象的时候,生成的json无限大了,然而内存不是无限大的(这特么不是废话吗),所以就出现这个问题了。他说,他知道这件事听起来像洒比,但这个是真人真事。然后给了一个关爱智障的笑脸符号。
可笑。
结论:
以后编写程序的时候得注意了,本来我师父(现在没师傅了,干什么度都困难,不开心)教育我说,对象中字段不能太多,对象不能太大,对象中尽量不要循环引用(像上面一样)。那时候我还不知道什么意思,就只知道这是规范,现在真的体验到了,才知道,这些规范不是没有道理的啊。
结尾墨迹:
说到笑话,讲几个这段时间遇到的。
1、遇到问题之后百度参考一下,这时候被一个不懂行的行内人嘲笑了,说:你们编程全靠百度啊,笑死我了。
她这么一说也笑死我了。
2、有人问,Android每次更新我们都做一次适配,上一次刚适配完7,又出来8了,我们很痛苦,你们有什么办法,能适配所有系统,以后出新系统就不用适配了。问的时候还特认真,特高傲的那种感觉。
真笑死人了,人家谷歌还没出新系统呢,你就想适配他新系统。
这么说吧,苹果12,13,14都没出呢,你就让我想一个办法,适配苹果20。哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈。
3、有一帅哥问木匠,瓦匠在和水泥的时候,水的比例应该怎么放。木匠说,啊咧?你问我?我上哪知道去。然后这个帅哥把木匠嘲笑了一番。哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈。