题记：
最近看了一篇关于架构方面的良心长文你的架构是怎样一步步腐化的？，文中字字句句道出了诸多从业者、初创企业，以及BAT都会遇到的问题，细细品读后认为工作生活中的诸多情况皆如此，都会有一个体量由小到大的增长过程，这就面临着怎样管理的问题。逐步优化 or 推倒重来？
背景：
博客中的【日积（Running）月累（ZSSURE）】系列，用于记录平日里学习和工作中遇到的问题。然并不意味着每一个问题都是多大的“坑”。作为程序猿应该都有过这种体会，“调试了一整天程序，结果发现是某个变量名称写错了。亦或是其它种种低级而low的错误……”。所谓的成长有其广度的一面。那就是你要随时准备接受新技术、新技能；同一时候也有其深度的一面，那就是静静思考。
非常多看似简单的问题，求根溯源找到解决方式就是一种常见的思考方式，是锤炼深度的必由之路。
对于初入职场的新人，往往会因为接触了新的技能、熟悉了新的领域而兴奋不已，总希望可以学习新的东西，可以追随大牛or大神的脚步。
随着时间的流逝兴趣、热情逐渐消散，到头来却是“竹篮子打水”，一无所获。
今年日常事务繁多。发现写博的量有所下降，自己虽不追求量，但细细回忆2015，似乎没有多少的收获，这从一个側面说明了在熙熙攘攘、纷繁吵杂的工作和生活中留给自己静静思考的时间少了，对知识、技能深度的把握少了。作家格拉德威尔在《异类》一书中指出：“人们眼中的天才之所以卓越非凡，并不是天资超人一等，而是付出了持续不断的努力。1万小时的锤炼是不论什么人从平庸变成超凡的必要条件。”这也就是“一万小时定律”。
细想一下，设：
每篇博文成文前思考整理时间是4（单位：小时），编写公布时间是2。那么，一万小时=10000/6=1667（篇）。依照平均每月4篇，须要34年（417个月）。还是蛮恐怖的一件事情，不是么？
问题&解决方式：
【问题1】 .NET中Task任务的取消
【问题描写叙述】：近日在监控基于WCF的DICOM服务模块时发现控制台总会莫名的多出一些线程（事实上是Task）占用系统资源，导致每隔一段时间须要重新启动服务才干彻底释放。
【问题根源】：通过调试跟踪。发如今响应不同用户需求时会出现中断之前需求的情况，然而此种情况下由被中断的操作所创建的Task任务却依旧在执行。
【解决方式】在Task任务内部使用CancellationTokenSource监控当前操作是否已被中断。
private readonly CancellationTokenSource _cts = new CancellationTokenSource();
public CancellationTokenSource CannelToken
{
get { return _cts; }
}
private void StartSubTaskUntilCancel()
{
Task.Factory.StartNew(new Action(() =>
{
while (true)
{
_cts.Token.ThrowIfCancellationRequested();
Thread.Sleep(500);
System.Console.WriteLine(DateTime.Now.ToLongTimeString());
}
}));
}关于Task任务的中断在WinForm界面开发中要额外注意，之前学习Task的用法时大多是在控制台下单独练习并未考虑到用户操作。以及WinForm中自身的消息循环机制。举例说明例如以下：
如上图所看到的，在主窗口“开启新窗口”button响应里，弹出子窗口TaskForm时启动了一个Task用于实时输出当前时间。
依照之前传统的思路，在TaskForm窗口中创建的Task在关闭窗口后会自己主动退出（这就是由控制台环境下练习导致的惯性思维）。
然而当我们关闭子窗口TaskForm时，会发现时间依旧在输出。那么怎样才干依据用户交互来是的Task适当退出呢？——就是上面提到的CancellationTokenSource。
在子窗口的FormClosed事件响应中调用CancellationTokenSource的Cancel方法就可以通知Task退出。在分析Task以及线程池时可以使用Process Explorer的.NET Performance
详细细节可參考博文8天玩转并行开发——第二天 Task的使用和C# CancellationTokenSource 终止线程。
【问题2】Telerik OpenAccess的记录删除
【问题描写叙述】在使用Telerik OpenAccess来作为数据库操作中间件时，须要删除相关的记录，包含单条记录和多条记录。
【解决方式】直接使用OpenAccessContext的Delete方法就可以。详情參考How to: Delete Objects
【问题3】fo-dicom的DcmDataset的DeepCopy和ShallowCopy
【问题描写叙述】在使用fo-dicom作为自有数据格式与DICOM格式相互转换时，发现终于转换成的DICOM文件的部分字段同样。都等于最后一次转换时所赋的值。
【问题根源】这个问题应该是因为fo-dicom的C-STORE发送机制以及对象的浅拷贝造成的。关于fo-dicom的C-STORE的流程參见之前的博文DICOM：fo-dicom之C-STORE再分析‘解决System.ObjectDisposedException异常’，对于C-STORE服务一般是先将全部的数据统一加入到待发送队列中，然后调用send命令统一发送。因为每次转换数据时使用的DcmDataset是同一个对象，对于部分字段并没有逐个进行深度拷贝。因此会导致终于全部DICOM文件的部分字段一致。
【解决方式】使用DcmDataset的CopyTo函数就可以解决。
DicomDataset tmpDataset = new DicomDataset();
dataset.CopyTo(tmpDataset);关于.NET的DeepCopy与ShallowCopy可參考博文Shallow Copy And Deep Copy。
作者：zssure@163.com
时间：2016-01-16