《我用段子讲.NET之依赖注入其二》
”随着我们将业务代码抽象化成接口和实现两部分，这也使得对象生命周期的统一管理成为可能。这就引发了第二个问题，.NET Core中的依赖注入框架。”
1听到董哥这么说，作为一位仅有3年左右经验的开发者小木同学一脸错愕，虽然这句话的每个词他都认识，但连在一起却犹如听天书。
”董哥，你说的第一句话，我倒是刚刚已经听你说明白了。但这第二句话却完全搞不懂。主要有两个问题，第一，什么叫做对象生命周期，其次，怎么实现统一管理的？”
董哥莞尔一笑：”那你觉得.NET对象是如何创建和销毁的？”
小木同学对这个话题并不陌生，他说：”对象的创建，一般用new关键词来创建，对象的销毁则一般使用对象继承自IDisposable，并在析构函数中释放。不过析构函数这种用法都是我在网上看到的，实际上没用过，这就属于对象生命周期管理吧？”
董哥说：”是的。”
小木继续说：”那按这个说法，我感觉.NET中不用刻意维护对象生命周期，垃圾回收机制会回收超出生命周期的对象吧。 ”
“事实上虽然.NET虽然会通Gc管理对象生命周期，实际上依然会面临这样的问题。这有点像我们可能看不到地球的存在，但我们存在，那地球也是客观存在的，只是平时我们没注意观察而已。
那你们的代码里面，估计没刻意控制过对象的创建过程，而且估计也经常使用静态变量吧。”
“额，是啊，我司生产代码里面出现得最多的，估计就是new 对象的语句，以及定义为public static的静态变量了，有一次我认真的观察了一下，几乎每个类都会定义几个静态变量。”
听到小木这么说，董哥被逗乐了：“听起来有点搞笑，不过我也知道，你们这种HIS系统，本来就是业务非常复杂，如何快速的完成项目才最重要。“
2董哥看到小木的杯子空了，又去给他加了一点水。
这时董哥窗外的湖面也掩映着一片夕阳的灿烂，微风吹过，粼粼波光，风景倒是挺雅致，不知不觉，已经临近6点半，他们围绕这个话题已经聊了快个把小时了，此时董哥他们办公室也迎来了下班高峰期，同事们渐次的离开办公室，但对技术爱好者来说，总是感觉不到时间流逝。
董哥回来后，把杯子递给小木，同时，也拿起自己的杯子喝了一口，他慢条斯理的说：
“在许多业务系统开发里面，内存仿佛不要钱，大不了就给医生们多加几根内存条，反正都是地方财政买单，也不会要开发人员出钱。再者，估计买内存条的钱，显然比优化代码付出的成本低，花那么多时间优化性能，有时确实反而付出了更高的时间成本。
而对于我们物联网嵌入式系统开发者来说，硬件基础设施都金贵着，有时稍微注意点，配置可能看起来差不多，但总价可以省出好几十块钱一台出来。如果生产量比较多，还能多赚不少钱。当然，并不是说.NET就不行，我们有的应用其实也在用.NET Core来开发，性能还挺不错的。“
小木也端起杯子喝了一口，回答道：
“也许只是我们公司是这样吧，估计那些大一点的公司会好许多。也有可能是.NET入门容易，没.NET Core那么多套路，所以很容易就放飞了。
那在.NET Core里面依赖注入框架是如何统一管理对象生命周期的？”
3董哥继续拿起了那张画了一棵树的纸，他说：”不仅对象间的依赖关系本身像一棵树，对象的生命周期管理，其实也像这一棵树。首先是主程序不断的new对象，然后对象再不断的new子对象。就像主干长出枝干，枝干长出叶子，结构越来越复杂。但对象如果不断的堆积在内存中，就会引发内存泄漏（oom）问题，导致程序崩溃。你听过值对象和引用对象么？“
小木点了点头：“听说值对象放在栈上，引用对象放在堆上。”
“是的，当然，值对象在业务开发中可能用得没那么多，所以造成内存占用的，主要还是放在堆上的对象。垃圾回收策略倒是只有一句话，引用计数，分代回收，对象压缩。0代，1代，2代，大对象堆，分别有不同的回收策略。不过这些可能对你来说理解暂时有点困难，有机会再慢慢说。“
”比较容易理解的可能是，对象回收并非一直在发生，它只有在系统物理内存不足，达到内存回收阈值，手动调用GC.Collect方法等情况下发生。而且垃圾回收过程并非对程序毫无副作用，在某些性能要求特别高的场景，例如高并发场景下，发生计划外的垃圾回收，可能会导致程序偶发性变得卡顿，可能会造成用户体验度的下降。这也是痛点，也就是依赖注入框架所能解决的第二个问题。统一的生命周期管理“
董哥突然变得严肃起来。