概述
JetBrains dotTrace(2020.01)
Tracing模式：耗時方法分析
Line-By-Line模式：耗時代碼行分析
JetBrains dotMemory(2020.01)
稀疏數組
析構隊列
1，JetBrains dotTrace性能診斷
JetBrains dotTrace是JetBrains家族的產品成員；它可以安裝集成再Visula studio中，也可以獨立使用；主要用於.NET平台下的性能分析；
該工具相對於Visula studio的診斷工具和windows性能監視器相比，對於定位性能的問題更加詳細；
截至2020年9月；JetBrains dotTrace最新版本是2020.2；JetBrains dotTrace是收費的；我沒有找到2020.2的破解版；使用的是2020.1的破解版的
下面來介紹一下JetBrains dotTrace2020.1在Visula studio2019環境下的使用（JetBrains dotTrace2020.1是要自己下載安裝的）
打開Visula studio2019的菜單上的"擴展"；選擇"ReSharper">"Profile">"Run Startup Configuration Performance Profiling"；如下圖
打開之后，你將會看到一個關於跟蹤模式的選項問話；一共有四種模式；如下說明
Simpling:獲取CLR內部的方法的開始時間，結束時間差，用於獲取程序的運行時間，分析速度快
Tracing:比Simpling慢，用於測量特定的方法被調用的次數，以及程序的時間差
Line-By-Line:收集每條代碼的運行時間來比較，計算出更加精確的運行時間；用於定位具體的性能語句時
TimeLine:類似於vs分析工具的性能抽樣的方式，可能會導致一些執行時間特別短的方法抓取不到
Tracing模式：方法調用時間分析Tracing模式
下面我們使用Tracing模式來進行測試，並查看每個方法的運行時間，調用次數等信息；如下運行測試后自動生成的報告
All Calls：以調用線程列表展現所有線程耗時；包含了查看自身調用時間，總調用時間
展開Main Thread主線程；點擊展開；你可以查看每一個線程上的各個方法的耗時情況，每個方法的開銷占比
點擊方法，還可以看到對應源碼
調用鏈視圖；與線程視圖不同；調用鏈視圖是以方法的維度查看方法的性能狀況；還可以展開方法的內部調用；
選擇某個方法；右鍵查看方法統計狀況屬性；可以看到更簡潔的性能統計視圖：總消耗時間，自消耗時間，平均消耗時間，調用次數等
如果你發現某些方法的自身調用時間占比比較低，那么說明真正調用時間較長的還在子方法調用，你可以選擇該方法，右鍵屬性查看所有方法；
查看指定方法的所有子方法
普通列表視圖；
視圖平鋪的方式展示所有被調用的方法，展示每個方法的平均調用，總調用時間，自身調用時間
熱點調用視圖；將性能監視最重要的，最消耗性能的相關調用在這進行展示
總覽視圖：以圖表方式展現概況
Line-By-Line模式：分析定位最耗時的代碼行
Tracing模式只能看到每一個方法，線程相關的調用時間；但是你無法定位到是那一段代碼，那一句代碼最耗時；
使用Line-By-Line模式可以分析定位最耗時的代碼行；如下Line-By-Line耗時統計結果，你可以看到每行調用次數
在"調用次數數值"旁邊有藍色橫條柱；用來標識每行代碼占用開銷的比例
數字是調用次數；藍色橫條是開銷占比
1，JetBrains dotMemory內存診斷
JetBrains dotMemory是JetBrains家族的產品成員；它可以安裝集成再Visula studio中，也可以獨立使用；主要用於.NET平台下的內存開銷的分析；
該工具相對於Visula studio的診斷工具，更加強大；
截至2020年9月；JetBrains dotMemory最新版本是2020.2；JetBrains dotTrace是收費的；我沒有找到2020.2的破解版；使用的是2020.1的破解版的；
一般情況下，在你安裝JetBrains dotTrace時，你也可以選擇安裝JetBrains dotMemory
下面來介紹一下JetBrains dotMemory2020.1在Visula studio2019環境下的使用（JetBrains dotMemory2020.1是要自己下載安裝的）
打開Visula studio2019的菜單上的"擴展"；選擇"ReSharper">"Profile">"Run Startup Project Memory Profiling"；在彈出的對話框中選擇Run(選擇默認值)
內存跟蹤界面
你可以看到當前的
總內存開銷；
非托管內存
GC的0-2代內存堆，大對象堆
移動到曲線圖上，你還可以每一個時間點上的內存狀況；如下圖
查看GC內存回收時的內存，持續時間內內存狀況；抓取內存快照
如托管堆的內存，總內存等
按上圖，點擊打開內存快照鏈接；查看內存快照更加詳細的視圖
你可以看到快照時間上，各個對象的內存分配狀況，最大可存活對象；以及常見的內存回收存在問題的診斷；如
Sparse Arrays(稀疏數組)
Finalizable Objects（析構隊列）
String duplicates(字符串重復)
如上圖，分析內存問題
存在大量Byte西數數組，就是數組中有很多都是默認值0；點擊查看占用內存開銷43.36MB的Byte[]對象；你會發現里面都是被0填充的
析構隊列：
回收對象時會調用對象的析構函數，垃圾回收時執行這些析構函數，那么使得垃圾回收的時間無法預料；
為了解決這個問題，.NET定義了析構線程和析構隊列；如果對象不再存活，而且你又定義了析構函數；那么對象將會被添加到析構隊列，並且標記它為存活；在本輪GC中將不會回收這些對象
GC結束后，析構線程會去取出析構隊列中的對象來執行析構函數，析構函數執行完畢的對象會在下一輪GC中回收
析構隊列存在大量Employee對象；是因為Employee重寫了析構函數；在析構函數中做了業務邏輯
導致Employee的回收速度比Employee的內存分配速度慢(一個在new，一個在釋放，釋放的速度比new的慢，這將會導致內存溢出)
如下析構函數
