前言
最近,在项目里遇到一个很 “诡异” 的问题。明明把后面需要使用的值存起来了,可是使用的时候,却拿到了一堆垃圾数据。有可能是什么原因呢?一起来看看吧。
2020
年基本上按照计划做到了周更。虽然每篇文章的阅读量都不高,但是每一篇都很用心的在写。能对一部分小伙伴儿有启发就值了。写这个公众号的初衷本来就是希望能给遇到相同或相似问题的小伙伴以启发。
2020
收获:
52+
篇原创文章。其中,一篇看雪精华,三篇优秀。不管怎样,令人沮丧的 2020
已经过去了,充满希望的 2021
已经来了。本公众号还会继续更新,但是更新频率会有所降低。
2021
为本公众号立几个 flag
,希望都能完成,欢迎各位朋友督促。
12
篇原创,争取做到每月一篇。12
本。2021
希望大家都有新的收获。包邮送四本技术书籍给大家。抽四个幸运儿,每人一本。下周一(2021
年 1
月 11
日)0
点开奖。
注意:本次抽奖仅限老粉丝(2021
年 1
月 4
日之前就关注了 公众号 【编程难】 或者 【比目信息】 的小伙伴儿)参与。
《软技能 代码之外的生存指南》
《程序员的自我修养:链接、装载与库》
《Effective C++:改善程序与设计的55个具体做法》
《深度探索C++对象模型》
今天的文章比较短,基本上全在视频里了。
这是一份有意思的 “内存泄漏” 视频。加上引号是因为虽然可以称作内存泄漏,但是又算不上真正意义上的内存泄漏。因为虽然短时间内内存暴增,但终归还是能释放掉的。
其实,这个 “内存泄漏” 背后隐藏着一个序列化/反序列化的 bug
。很早之前就碰到了这个问题,只不过当时并没有录下来。当时的情况比现在更加明显——内存很快的从 1 GB
增长到 5 GB
左右,然后再释放掉,再增长,再释放,如此往复。不像这次,增长到 4 GB
多的时候,会有一个比较长的停留,然后才释放。
这个问题的根本原因是序列化与反序列化不匹配导致的。在特定环境下定位并解决这种问题是相对容易的,因为问题范围很小,而且对相关源码比较熟悉。具体排除过程没什么好说的。
其实,定位这种问题可以像我在视频里那样用 process explorer
的线程查看功能,粗略查看一下原因。运气好的话,基本可以很快定位。
话不多说,欣赏视频吧!注意视频中红色箭头和红色方框高亮的部分。