是个人，他能想得到，是记录文件出的问题？----序
通过这篇文章，希望大家可以理解我们的思想，同时明白一个道理——没人说过会编程的就是程序员。
今天，好不容易盼来了一天的假期，我立即开始软件的开发，为了绝对保证用户的隐私，我们将数据文件存在本地。在我完成了主界面的大改之后，出现了一个奇怪的问题。
主界面
软件在启动时变得十分卡顿，幸亏VS自带一个分析器，让我知道是内存方面出的问题。正常情况下我的软件的内存占用大概是30MB左右，但现在，看看这飙上天际的占用率！看看这无休无止的GC！这样的情况一定会使用户无比痛苦，所以我觉定一定要解决它。
内存分析
以正常人的思路，我认为一定是新加入的圆角效果调用了太多的WindowsAPI导致的结果，于是我先去掉了浮动提示框的圆角效果，然后重新启动软件，一切照旧，依然卡顿。
于是我关闭软件，但这一次不是终止调试，而是通过软件上的按钮关闭的。这一关闭更大的问题出现了，软件直接卡死在了那里，内存占用更是一路飚飞到了200MB，并且出现了满满的GC。
内存分析
这让我找到了关键所在，于是我截取了启动时的内存快照与关闭时的内存快照各一份，发现它们之间出现了巨大的差异。VS还内置了内存分析器与内存查看器，于是我随便找了一个快照丢了进去。这不看不知道，一看吓一跳，我迅速定位了一组不同寻常的数据。
内存分析
很显然，内存中出现了22 274个时钟对象、22 273个按钮对象以及111 591个链表。这不由得让我想到命名空间中的Plan类型，每个Plan含有一个时钟、一个按钮与5个链表。结合代码度量值，我确定了问题在于内存中出现了数量惊人的任务对象。在这次的试运行中，我只创建了了两个任务，那么其他22 271个任务是从哪里来的呢？带着这个疑惑，我打开了类查找器，看到了该类型的15个引用。
引用
引用中的链表是十分可疑的，一路摸过去，我发现是这个玩意儿存储了两万多个对象。到这里，事情的真相全部揭晓，窗口在打开和关闭时都需要读取已经保存的计划，所以才会卡死。我找到了那个存储文件，果然，那个文件足足有22 271行，重建那个文件，重新启动程序。
文件
程序恢复正常运行，未产生GC及任何遗留问题。
正常
网友评论