dottrace都能干什么
看内存泄漏、看cpu过高、查内存分配过高的原因、查方法执行比较慢、查UI线程卡顿等等。
内存泄漏
指的是内存该释放的不释放，最终导致程序内存慢慢攀升，慢慢地程序卡的不行了或者OOM闪退。
托管内存的泄漏
如：事件+=后忘记-=，这种泄漏很多开发者压根儿没放心上过；其它好像还真想不出来能让托管内存泄漏的场景！-- 有很多.net开发者整个开发生涯都没为托管内存泄漏这事儿担心过；
非托管内存泄漏
如：你手动申请了一块儿空间，
var blockPtr= Marshal.AllocHGlobal(1024*1024*4);//申请一个4k的空间//一些业务逻辑Marshal.FreeHGlobal(blockPtr);
你没有保证它一定能够释放：比如，在处理业务时你的程序异常了，Marshal.FreeHGlobal(blockPtr);没执行到，故非托管内存泄漏。
关于内存过高
有时候你无意中加载一个2k左右的图片，都有可能撑爆内存。内存短时间内爆高还回落的比较慢，这也是一个很危险的事情。。。
关于CPU过高
它就像人的心跳一样，心率过高对人的健康好么？常见的CPU过高的原因有：不小心写出来了一个死循环，由于你在一个Task或者Thread中写的，没报错但CPU就是高，这在线上找起来就很苦恼。
关于UI线程卡顿
现象就是你的软件没死，但是点不动按钮或者操作其它有交互的元素也没反应了，疯狂点击鼠标之后可能会程序还会崩溃。这个现象对WPF开发者再熟悉不过了，这是一种主UI线程，执行耗时操作导致的；譬如：点击了一个按钮后，你在点击事件处理程序中去读取一个超大大文件或者同步请求一个长耗时接口。
以上dotTrace都能轻松解决，而且不像windbg和perfview那些工具那样要么需要敲命令、要么界面难以看懂。dotTrace几乎都是动动鼠标，点一点就可以看出症结所在！！！
开始实战
dottrace最长采用的TimeLine时间线分析方式，即：你给dotTrace附加到待调试程序后，开启采样--->你觉得已经采样到了你的问题--->结束采样；这段时间发生的事情都被dotTrace记录，再往后的分析就是以这段时间的采样数据作为依据的。
参考：开始使用时间线分析
分析非托管内存占用
谁能看非托管内存 除了Windbg还有两个工具：perfview 免费(当前我的win11系统是arm架构的，perfview竟然用不了！！)、 dottrace(付费)。
因为需要看非托管内存，所以要把这个开关打开 另外为了保证性能 我们遵从小字部分的提示，只收集未释放的部分
我写了这样一段代码，故意在c程序中malloc了一块儿空间但不释放它，让dottrace看看能不能分析到这块儿内存是哪里创建的。
使用dottrace附加到进程上，能直接看到哪个堆栈调用分配了这块内存
可以看到，dotTrace还真的分析到了 有块儿非托管内存，是因manualAllocBtn_Click方法调用了 test();才分配出来的。
分析UI卡顿(冻结)
我写了一段代码，当点击按钮后，将线程sleep两秒，来模拟Ui卡顿。
分析ui冻结，是dotTrace最擅长的事情，当附加到进程后，点击几次按钮把UI卡顿现象复现几次给dotTrace，然后点击采样结束。
分析器左侧有 UI Freeze 筛选器，勾选上它右侧时间轴上就只剩下 UI卡顿的操作了。
分析慢方法
当你对整个程序中各个方法的耗时比较感兴趣时，dotTrace可以快速帮你把采样期间方法的耗时排一个排行榜。那么整个项目的耗时点就找出来了。需要优化降低耗时就有依据了。
比如我这里模拟发起几个任务，他们执行时长各不相同
那么dotTrace能够找到他们谁耗时最长么？
从上图可以看出，dotTrace精准地判断出，最耗时的方法是我上面写的几个Taskx方法。
分析CPU爆高
鼠标动两下，就把高CPU占比的地方给找了出来。这一招从哪儿学的？DotTrace官网就有类似的动图教程：查找并选择高 CPU 使用率的时间间隔
其实visual studio也可以排查出来cpu爆高问题，vs调试代码时，自带的诊断工具，录制一段后，它会以图表形式给出cpu的占用率排行榜
如下图：图片来自使用性能探查器中的 CPU 分析来分析性能
分析死锁
我写了一个死锁的简单示例，即：点击按钮，在处理程序中因同步调用了异步方法且访问了Result属性，导致UI线程死锁。
其实这个让vs做更擅长，如果卡死/死锁，发生在用户现场，
步骤大概是：
第一步：在任务管理器中将程序创建dump文件，
第二步：开发人员难道dump文件后，使用visual studio打开，
vs分析死锁，最简单的方式是 点击“运行诊断分析” 如果有死锁就可以在“已找到阻止线程的同步对象”的诊断结果中找到死锁位置。
大致操作步骤如下：
另一种方式是，点击调试点击"暂停调试"
如果是，ui线程死锁暂停一次就可以看出效果；
如果是，非ui线程的死锁，可以暂停多次，如果多次都暂停到那个位置(且这个位置不是框架层代码)，那多半就是这里死锁了。
所以我特意写了一段非UI线程的死锁，来演示：
当你打开dump文件后，程序会直接暂停到死锁位置处
