非同步編程：使用線程池管理線程

来源:http://www.cnblogs.com/nov5026/archive/2016/08/17/5779949.html
-Advertisement-
Play Games

非同步編程：使用線程池管理線程 從此圖中我們會發現 .NET 與C# 的每個版本發佈都是有一個“主題”。即：C#1.0托管代碼→C#2.0泛型→C#3.0LINQ→C#4.0動態語言→C#5.0非同步編程。現在我為最新版本的“非同步編程”主題寫系列分享，期待你的查看及點評。 如今的應用程式越來越複雜，我們 ...


非同步編程：使用線程池管理線程

 從此圖中我們會發現 .NET 與C# 的每個版本發佈都是有一個“主題”。即：C#1.0托管代碼→C#2.0泛型→C#3.0LINQ→C#4.0動態語言→C#5.0非同步編程。現在我為最新版本的“非同步編程”主題寫系列分享，期待你的查看及點評。

 

如今的應用程式越來越複雜，我們常常需要使用《非同步編程：線程概述及使用》中提到的多線程技術來提高應用程式的響應速度。這時我們頻繁的創建和銷毀線程來讓應用程式快速響應操作，這頻繁的創建和銷毀無疑會降低應用程式性能，我們可以引入緩存機制解決這個問題，此緩存機制需要解決如：緩存的大小問題、排隊執行任務、調度空閑線程、按需創建新線程及銷毀多餘空閑線程……如今微軟已經為我們提供了現成的緩存機制：線程池

         線程池原自於對象池，在詳細解說明線程池前讓我們先來瞭解下何為對象池。

流程圖：

 

 

         對於對象池的清理通常設計兩種方式：

1)         手動清理，即主動調用清理的方法。

2)         自動清理，即通過System.Threading.Timer來實現定時清理。

 

關鍵實現代碼：

 

  
public sealed class ObjectPool<T> where T : ICacheObjectProxy<T>
{
    // 最大容量
    private Int32 m_maxPoolCount = 30;
    // 最小容量
    private Int32 m_minPoolCount = 5;
    // 已存容量
    private Int32 m_currentCount;
    // 空閑+被用 對象列表
    private Hashtable m_listObjects;
    // 最大空閑時間
    private int maxIdleTime = 120;
    // 定時清理對象池對象
    private Timer timer = null;
 
    /// <summary>
    /// 創建對象池
    /// </summary>
    /// <param name="maxPoolCount">最小容量</param>
    /// <param name="minPoolCount">最大容量</param>
    /// <param name="create_params">待創建的實際對象的參數</param>
    public ObjectPool(Int32 maxPoolCount, Int32 minPoolCount, Object[] create_params){ }
 
    /// <summary>
    /// 獲取一個對象實例
    /// </summary>
    /// <returns>返回內部實際對象，若返回null則線程池已滿</returns>
    public T GetOne(){ }
 
    /// <summary>
    /// 釋放該對象池
    /// </summary>
    public void Dispose(){ }
 
    /// <summary>
    /// 將對象池中指定的對象重置並設置為空閑狀態
    /// </summary>
    public void ReturnOne(T obj){ }
 
    /// <summary>
    /// 手動清理對象池
    /// </summary>
    public void ManualReleaseObject(){ }
 
    /// <summary>
    /// 自動清理對象池（對大於 最小容量 的空閑對象進行釋放）
    /// </summary>
    private void AutoReleaseObject(Object obj){ }
}
實現的關鍵代碼

 

通過對“對象池”的一個大體認識能幫我們更快理解線程池。

 

線程池ThreadPool類詳解

ThreadPool靜態類，為應用程式提供一個由系統管理的輔助線程池，從而使您可以集中精力於應用程式任務而不是線程管理。每個進程都有一個線程池,一個Process中只能有一個實例，它在各個應用程式域（AppDomain）是共用的。

在內部，線程池將自己的線程劃分工作者線程(輔助線程)和I/O線程。前者用於執行普通的操作，後者專用於非同步IO，比如文件和網路請求，註意，分類並不說明兩種線程本身有差別，內部依然是一樣的。

public static class ThreadPool
{
    // 將操作系統句柄綁定到System.Threading.ThreadPool。
    public static bool BindHandle(SafeHandle osHandle);
 
    // 檢索由ThreadPool.GetMaxThreads(Int32,Int32)方法返回的最大線程池線程數和當前活動線程數之間的差值。
    public static void GetAvailableThreads(out int workerThreads
            , out int completionPortThreads);
 
    // 設置和檢索可以同時處於活動狀態的線程池請求的數目。
    // 所有大於此數目的請求將保持排隊狀態，直到線程池線程變為可用。
    public static bool SetMaxThreads(int workerThreads, int completionPortThreads);
    public static void GetMaxThreads(out int workerThreads, out int completionPortThreads);
    // 設置和檢索線程池在新請求預測中維護的空閑線程數。
    public static bool SetMinThreads(int workerThreads, int completionPortThreads);
    public static void GetMinThreads(out int workerThreads, out int completionPortThreads);
 
    // 將方法排入隊列以便執行，並指定包含該方法所用數據的對象。此方法在有線程池線程變得可用時執行。
    public static bool QueueUserWorkItem(WaitCallback callBack, object state);
    // 將重疊的 I/O 操作排隊以便執行。如果成功地將此操作排隊到 I/O 完成埠，則為 true；否則為 false。
    // 參數overlapped:要排隊的System.Threading.NativeOverlapped結構。
    public static bool UnsafeQueueNativeOverlapped(NativeOverlapped* overlapped);
    // 將指定的委托排隊到線程池，但不會將調用堆棧傳播到工作者線程。
    public static bool UnsafeQueueUserWorkItem(WaitCallback callBack, object state);
 
    // 註冊一個等待Threading.WaitHandle的委托，並指定一個 32 位有符號整數來表示超時值（以毫秒為單位）。
    // executeOnlyOnce如果為 true，表示在調用了委托後，線程將不再在waitObject參數上等待；
    // 如果為 false，表示每次完成等待操作後都重置計時器，直到註銷等待。
    public static RegisteredWaitHandle RegisterWaitForSingleObject(
            WaitHandle waitObject
            , WaitOrTimerCallback callBack, object state, 
            Int millisecondsTimeOutInterval, bool executeOnlyOnce);
    public static RegisteredWaitHandle UnsafeRegisterWaitForSingleObject(
              WaitHandle waitObject
            , WaitOrTimerCallback callBack
            , object state
            , int millisecondsTimeOutInterval
            , bool executeOnlyOnce);
    ……
}
ThreadPool
  1. 線程池線程數

1)         使用GetMaxThreads()和SetMaxThreads()獲取和設置最大線程數

可排隊到線程池的操作數僅受記憶體的限制；而線程池限制進程中可以同時處於活動狀態的線程數（預設情況下，限制每個 CPU 可以使用 25 個工作者線程和 1,000 個 I/O 線程(根據機器CPU個數和.net framework版本的不同，這些數據可能會有變化)），所有大於此數目的請求將保持排隊狀態，直到線程池線程變為可用。

不建議更改線程池中的最大線程數：

a)         將線程池大小設置得太大，可能會造成更頻繁的執行上下文切換及加劇資源的爭用情況。

b)         其實FileStream的非同步讀寫,非同步發送接受Web請求,System.Threading.Timer定時器,甚至使用delegate的beginInvoke都會預設調用 ThreadPool,也就是說不僅你的代碼可能使用到線程池,框架內部也可能使用到。

c)         一個應用程式池是一個獨立的進程,擁有一個線程池,應用程式池中可以有多個WebApplication,每個運行在一個單獨的AppDomain中,這些WebApplication公用一個線程池。

 

2)         使用GetMinThreads()和SetMinThreads()獲取和設置最小空閑線程數

為避免向線程分配不必要的堆棧空間，線程池按照一定的時間間隔創建新的空閑線程（該間隔為半秒）。所以如果最小空閑線程數設置的過小，在短期內執行大量任務會因為創建新空閑線程的內置延遲導致性能瓶頸。最小空閑線程數預設值等於機器上的CPU核數，並且不建議更改最小空閑線程數。

在啟動線程池時，線程池具有一個內置延遲，用於啟用最小空閑線程數，以提高應用程式的吞吐量。

線上程池運行中，對於執行完任務的線程池線程，不會立即銷毀，而是返回到線程池，線程池會維護最小的空閑線程數(即使應用程式所有線程都是空閑狀態)，以便隊列任務可以立即啟動。超過此最小數目的空閑線程一段時間沒事做後會自己醒來終止自己，以節省系統資源。

3)         靜態方法GetAvailableThreads()

通過靜態方法GetAvailableThreads()返回的線程池線程的最大數目和當前活動數目之間的差值，即獲取線程池中當前可用的線程數目

4)         兩個參數

方法GetMaxThreads()、SetMaxThreads()、GetMinThreads()、SetMinThreads()、GetAvailableThreads()鈞包含兩個參數。參數workerThreads指工作者線程；參數completionPortThreads指非同步 I/O 線程。

  1. 排隊工作項

通過調用 ThreadPool.QueueUserWorkItem 並傳遞 WaitCallback 委托來使用線程池。也可以通過使用 ThreadPool.RegisterWaitForSingleObject 並傳遞 WaitHandle（在向其發出信號或超時時，它將引發對由 WaitOrTimerCallback 委托包裝的方法的調用）來將與等待操作相關的工作項排隊到線程池中。若要取消等待操作（即不再執行WaitOrTimerCallback委托），可調用RegisterWaitForSingleObject()方法返回的RegisteredWaitHandle的 Unregister 方法。

如果您知道調用方的堆棧與在排隊任務執行期間執行的所有安全檢查不相關，則還可以使用不安全的方法 ThreadPool.UnsafeQueueUserWorkItem 和 ThreadPool.UnsafeRegisterWaitForSingleObject。QueueUserWorkItem 和 RegisterWaitForSingleObject 都會捕獲調用方的堆棧，此堆棧將線上程池線程開始執行任務時合併到線程池線程的堆棧中。如果需要進行安全檢查，則必須檢查整個堆棧，但它還具有一定的性能開銷。使用“不安全的”方法調用並不會提供絕對的安全，但它會提供更好的性能。

  1. 在一個內核構造可用時調用一個方法

讓一個線程不確定地等待一個內核對象進入可用狀態，這對線程的記憶體資源來說是一種浪費。ThreadPool.RegisterWaitForSingleObject()為我們提供了一種方式：在一個內核對象變得可用的時候調用一個方法。

使用需註意：

1)         WaitOrTimerCallback委托參數，該委托接受一個名為timeOut的Boolean參數。如果 WaitHandle 在指定時間內沒有收到信號（即，超時），則為true，否則為 false。回調方法可以根據timeOut的值來針對性地採取措施。

2)         名為executeOnlyOnce的Boolean參數。傳true則表示線程池線程只執行回調方法一次；若傳false則表示內核對象每次收到信號，線程池線程都會執行回調方法。等待一個AutoResetEvent對象時，這個功能尤其有用。

3)         RegisterWaitForSingleObject()方法返回一個RegisteredWaitHandle對象的引用。這個對象標識了線程池正在它上面等待的內核對象。我們可以調用它的Unregister(WaitHandle waitObject)方法取消由RegisterWaitForSingleObject()註冊的等待操作(即WaitOrTimerCallback委托不再執行)。Unregister(WaitHandle waitObject)的WaitHandle參數表示成功取消註冊的等待操作後線程池會向此對象發出信號(set())，若不想收到此通知可以傳遞null。

         示例：

private static void Example_RegisterWaitForSingleObject()
{
    // 加endWaitHandle的原因：如果執行過快退出方法會導致一些東西被釋放，造成排隊的任務不能執行，原因還在研究
    AutoResetEvent endWaitHandle = new AutoResetEvent(false);
 
    AutoResetEvent notificWaitHandle = new AutoResetEvent(false);
    AutoResetEvent waitHandle = new AutoResetEvent(false);
    RegisteredWaitHandle registeredWaitHandle = ThreadPool.RegisterWaitForSingleObject(
        waitHandle,
        (Object state, bool timedOut) =>
        {
            if (timedOut)
                Console.WriteLine("RegisterWaitForSingleObject因超時而執行");
            else
                Console.WriteLine("RegisterWaitForSingleObject收到WaitHandle信號");
        },
        null, TimeSpan.FromSeconds(2), true
     );
 
    // 取消等待操作（即不再執行WaitOrTimerCallback委托）
    registeredWaitHandle.Unregister(notificWaitHandle);
 
    // 通知
    ThreadPool.RegisterWaitForSingleObject(
        notificWaitHandle,
        (Object state, bool timedOut) =>
        {
            if (timedOut)
                Console.WriteLine("第一個RegisterWaitForSingleObject沒有調用Unregister()");
            else
                Console.WriteLine("第一個RegisterWaitForSingleObject調用了Unregister()");
 
            endWaitHandle.Set();
        },
        null, TimeSpan.FromSeconds(4), true
     );
 
    endWaitHandle.WaitOne();
}
示例

執行上下文

         上一小節中說到：線程池最大線程數設置過大可能會造成Windows頻繁執行上下文切換，降低程式性能。對於大多數園友不會滿意這樣的回答，我和你一樣也喜歡“知其然，再知其所以然”。

  1. 上下文切換中的“上下文”是什麼？

.NET中上下文太多，我最後得出的結論是：上下文切換中的上下文專指“執行上下文”。

執行上下文包括：安全上下文、同步上下文(System.Threading.SynchronizationContext)、邏輯調用上下文(System.Runtime.Messaging.CallContext)。即：安全設置（壓縮棧、Thread的Principal屬性和Windows身份）、宿主設置（System.Threading.HostExcecutingContextManager）以及邏輯調用上下文數據(System.Runtime.Messaging.CallContext的LogicalSetData()和LogicalGetData()方法)。

  1. 何時執行“上下文切換”？

當一個“時間片”結束時，如果Windows決定再次調度同一個線程，那麼Windows不會執行上下文切換。如果Windows調度了一個不同的線程，這時Windows執行線程上下文切換。

  1. “上下文切換”造成的性能影響

         當Windows上下文切換到另一個線程時，CPU將執行一個不同的線程，而之前線程的代碼和數據還在CPU的高速緩存中，（高速緩存使CPU不必經常訪問RAM，RAM的速度比CPU高速緩存慢得多），當Windows上下文切換到一個新線程時，這個新線程極有可能要執行不同的代碼並訪問不同的數據，這些代碼和數據不在CPU的高速緩存中。因此，CPU必須訪問RAM來填充它的高速緩存，以恢復高速執行狀態。但是，在其“時間片”執行完後，一次新的線程上下文切換又發生了。

上下文切換所產生的開銷不會換來任何記憶體和性能上的收益。執行上下文所需的時間取決於CPU架構和速度（即“時間片”的分配）。而填充CPU緩存所需的時間取決於系統運行的應用程式、CPU、緩存的大小以及其他各種因素。所以，無法為每一次線程上下文切換的時間開銷給出一個確定的值，甚至無法給出一個估計的值。唯一確定的是，如果要構建高性能的應用程式和組件，就應該儘可能避免線程上下文切換。

除此之外，執行垃圾回收時，CLR必須掛起(暫停)所有線程，遍歷它們的棧來查找根以便對堆中的對象進行標記，再次遍歷它們的棧(有的對象在壓縮期間發生了移動，所以要更新它們的根)，再恢復所有線程。所以，減少線程的數量也會顯著提升垃圾回收器的性能。每次使用一個調試器並遇到一個斷點，Windows都會掛起正在調試的應用程式中的所有線程，併在單步執行或運行應用程式時恢復所有線程。因此，你用的線程越多，調試體驗也就越差。

  1. 監視Windows上下文切換工具

Windows實際記錄了每個線程被上下文切換到的次數。可以使用像Microsoft Spy++這樣的工具查看這個數據。這個工具是Visual Studio附帶的一個小工具(vs按安裝路徑\Visual Studio 2012\Common7\Tools)，如圖

  1. 執行上下文類詳解

在《非同步編程：線程概述及使用》中我提到了Thread的兩個上下文，即：

1)         CurrentContext        獲取線程正在其中執行的當前上下文。主要用於線程內部存儲數據。

2)         ExecutionContext    獲取一個System.Threading.ExecutionContext對象，該對象包含有關當前線程的各種上下文的信息。主要用於線程間數據共用。

其中獲取到的System.Threading.ExecutionContext就是本小節要說的“執行上下文”。

public sealed class ExecutionContext : IDisposable, ISerializable
{
    public void Dispose();
    public void GetObjectData(SerializationInfo info, StreamingContext context);
 
    // 此方法對於將執行上下文從一個線程傳播到另一個線程非常有用。
    public ExecutionContext CreateCopy();
    // 從當前線程捕獲執行上下文的一個副本。
    public static ExecutionContext Capture();
    // 在當前線程上的指定執行上下文中運行某個方法。
    public static void Run(ExecutionContext executionContext, ContextCallback callback, object state);
 
    // 取消執行上下文在非同步線程之間的流動。
    public static AsyncFlowControl SuppressFlow();
    public static bool IsFlowSuppressed();
    // RestoreFlow  撤消以前的 SuppressFlow 方法調用的影響。
    // 此方法由 SuppressFlow 方法返回的 AsyncFlowControl 結構的 Undo 方法調用。
    // 應使用 Undo 方法（而不是 RestoreFlow 方法）恢復執行上下文的流動。
    public static void RestoreFlow();
}
View Code

ExecutionContext 類提供的功能讓用戶代碼可以在用戶定義的非同步點之間捕獲和傳輸此上下文。公共語言運行時(CLR)確保在托管進程內運行時定義的非同步點之間一致地傳輸 ExecutionContext。

每當一個線程(初始線程)使用另一個線程(輔助線程)執行任務時，CLR會將前者的執行上下文流向（複製到）輔助線程（註意這個自動流向是單方向的）。這就確保了輔助線程執行的任何操作使用的是相同的安全設置和宿主設置。還確保了初始線程的邏輯調用上下文可以在輔助線程中使用。

但執行上下文的複製會造成一定的性能影響。因為執行上下文中包含大量信息，而收集所有這些信息，再把它們複製到輔助線程，要耗費不少時間。如果輔助線程又採用了更多地輔助線程，還必須創建和初始化更多的執行上下文數據結構。

所以，為了提升應用程式性能，我們可以阻止執行上下文的流動。當然這隻有在輔助線程不需要或者不訪問上下文信息的時候才能進行阻止。

下麵給出一個示例為了演示：

1)         線上程間共用邏輯調用上下文數據（CallContext）。

2)         為了提升性能，阻止\恢復執行上下文的流動。

3)         在當前線程上的指定執行上下文中運行某個方法。

private static void Example_ExecutionContext()
{
    CallContext.LogicalSetData("Name", "小紅");
    Console.WriteLine("主線程中Name為：{0}", CallContext.LogicalGetData("Name"));
 
    // 1)   線上程間共用邏輯調用上下文數據（CallContext）。
    Console.WriteLine("1)線上程間共用邏輯調用上下文數據（CallContext）。");
    ThreadPool.QueueUserWorkItem((Object obj) 
        => Console.WriteLine("ThreadPool線程中Name為：\"{0}\"", CallContext.LogicalGetData("Name")));
    Thread.Sleep(500);
    Console.WriteLine();
    // 2)   為了提升性能，取消\恢復執行上下文的流動。
    ThreadPool.UnsafeQueueUserWorkItem((Object obj)
        => Console.WriteLine("ThreadPool線程使用Unsafe非同步執行方法來取消執行上下文的流動。Name為：\"{0}\""
        , CallContext.LogicalGetData("Name")), null);
    Console.WriteLine("2)為了提升性能，取消/恢復執行上下文的流動。");
    AsyncFlowControl flowControl = ExecutionContext.SuppressFlow();
    ThreadPool.QueueUserWorkItem((Object obj) 
        => Console.WriteLine("(取消ExecutionContext流動)ThreadPool線程中Name為：\"{0}\"", CallContext.LogicalGetData("Name")));
    Thread.Sleep(500);
    // 恢復不推薦使用ExecutionContext.RestoreFlow()
    flowControl.Undo();
    ThreadPool.QueueUserWorkItem((Object obj) 
        => Console.WriteLine("(恢復ExecutionContext流動)ThreadPool線程中Name為：\"{0}\"", CallContext.LogicalGetData("Name")));
    Thread.Sleep(500);
    Console.WriteLine();
    // 3)   在當前線程上的指定執行上下文中運行某個方法。(通過獲取調用上下文數據驗證)
    Console.WriteLine("3)在當前線程上的指定執行上下文中運行某個方法。(通過獲取調用上下文數據驗證)");
    ExecutionContext curExecutionContext = ExecutionContext.Capture();
    ExecutionContext.SuppressFlow();
    ThreadPool.QueueUserWorkItem(
        (Object obj) =>
        {
            ExecutionContext innerExecutionContext = obj as ExecutionContext;
            ExecutionContext.Run(innerExecutionContext, (Object state) 
                => Console.WriteLine("ThreadPool線程中Name為：\"{0}\""<br>                       , CallContext.LogicalGetData("Name")), null);
        }
        , curExecutionContext
     );
}
View Code

結果如圖：

 

 

 註意：

1)         示例中“在當前線程上的指定執行上下文中運行某個方法”：代碼中必須使用ExecutionContext.Capture()獲取當前執行上下文的一個副本。

a)         若直接使用Thread.CurrentThread.ExecutionContext則會報“無法應用以下上下文: 跨 AppDomains 封送的上下文、不是通過捕獲操作獲取的上下文或已作為 Set 調用的參數的上下文。”錯誤。

b)         若使用Thread.CurrentThread.ExecutionContext.CreateCopy()會報“只能複製新近捕獲(ExecutionContext.Capture())的上下文”。

2)         取消執行上下文流動除了使用ExecutionContext.SuppressFlow()方式外。還可以通過使用ThreadPool的UnsafeQueueUserWorkItem 和 UnsafeRegisterWaitForSingleObject來執行委托方法。原因是不安全的線程池操作不會傳輸壓縮堆棧。每當壓縮堆棧流動時，托管的主體、同步、區域設置和用戶上下文也隨之流動。

 

線程池線程中的異常

線程池線程中未處理的異常將終止進程。以下為此規則的三種例外情況： 
1. 由於調用了 Abort，線程池線程中將引發ThreadAbortException。 
2. 由於正在卸載應用程式域，線程池線程中將引發AppDomainUnloadedException。 
3. 公共語言運行庫或宿主進程將終止線程。

何時不使用線程池線程

現在大家都已經知道線程池為我們提供了方便的非同步API及托管的線程管理。那麼是不是任何時候都應該使用線程池線程呢？當然不是，我們還是需要“因地制宜”的，在以下幾種情況下，適合於創建並管理自己的線程而不是使用線程池線程：

  1. 需要前臺線程。(線程池線程“始終”是後臺線程)
  2. 需要使線程具有特定的優先順序。(線程池線程都是預設優先順序，“不建議”進行修改)
  3. 任務會長時間占用線程。由於線程池具有最大線程數限制，因此大量占用線程池線程可能會阻止任務啟動。
  4. 需要將線程放入單線程單元(STA)。(所有ThreadPool線程“始終”是多線程單元(MTA)中)
  5. 需要具有與線程關聯的穩定標識，或使某一線程專用於某一任務。

 

 

　　本博文介紹線程池以及其基礎對象池，ThreadPool類的使用及註意事項，如何排隊工作項到線程池，執行上下文及線程上下文傳遞問題…… 

線程池雖然為我們提供了非同步操作的便利，但是它不支持對線程池中單個線程的複雜控制致使我們有些情況下會直接使用Thread。並且它對“等待”操作、“取消”操作、“延續”任務等操作比較繁瑣，可能迫使你從新造輪子。微軟也想到了，所以在.NET4.0的時候加入了“並行任務”併在.NET4.5中對其進行改進，想瞭解“並行任務”的園友可以先看看《（譯）關於Async與Await的FAQ》。

本節到此結束，感謝大家的觀賞。贊的話還請多推薦啊 (*^_^*)

 

 

 

 

參考資料：《CLR via C#(第三版)》

 

 摘自：http://www.cnblogs.com/heyuquan/archive/2012/12/23/threadPool-manager.html

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 在控制臺中承載WCF服務，並提供Ajax訪問和SOAP訪問，以及跨域訪問
    WCF服務可以承載與iis、winform、console、window服務中，下麵重點介紹以console為載體，對外提供服務（服務滿足web訪問以及soap方式訪問） 1.服務類的實現 wcf服務類一般有兩種實現方式，下麵分別對兩種方式進行介紹： 1.1 使用介面進行實現 1 namespace ...
  • MVC路由自定義及視圖找尋規則
    這篇關於MVC路由及視圖規則本來是昨天要發的，但是本人真的有點懶，終於今天忍無可忍了。初學MVC的時候比現在還菜一點（現在也很菜），想著會用就行，但是有時還是會好奇，為什麼它能找到控制器？為什麼控制器return View();就能找到視圖，而為什麼視圖一定要建在Views文件下？好像說的有點多了， ...
  • log4net配置文件管理
    以前使用log4net的時候老是在糾結配置log4net，總會發生配置文件不生效的情況，最後會發現其實是配置文件沒有拷貝到log4net的運行目錄，還真是糾結。現在好了，通過將文件當作嵌入的資源，然後初始化的時候載入下配置文件，這個問題完美解決。下麵方法如下： 1、將配置文件加入到當前.net相關的 ...
  • SharpGL學習筆記(二) 模型變換
    (二) 模型變換 模形變換就是指的在世界坐標系中(world space)做“移動”，“旋轉", "縮放"三種操作。 首先要說明的，在Opengl中，是用4x4矩陣進行坐標變換，OpenGL的4x4矩陣是按列排列的，就像下麵這樣。 所謂的模型變換，就是對這個矩陣進行變換。 描述三維世界你就得先設計三 ...
  • SSL通信-忽略證書認證錯誤
    .NET的SSL通信過程中，使用的證書可能存在各種問題，某種情況下可以忽略證書的錯誤繼續訪問。 經過下麵的處理伺服器證書驗證中不會有錯誤發生，證書認證一直通過，並正常通信 1.設置回調屬性ServicePointManager.ServerCertificateValidationCallback ...
  • 如果你也會C#，那不妨瞭解下F#（3）：F#集合類型和其他核心類型
    本文鏈接： 在第一篇中，我們介紹了一些基礎數據類型，其實那篇標題中不應該含有“F ”字眼，因為並不是特有的。 在本篇中，我們介紹如數組這些集合類型以及部分F 特有的類型。 在第一篇里我們列了一個從0加到100的代碼段，瞭解函數式編程的同學會說那個F 代碼不正宗。 而現在的C 開發一般也會使用Linq ...
  • Hibernate之lazy延遲載入（轉）
    一.延遲載入的概念 當Hibernate從資料庫中載入某個對象時，不載入關聯的對象，而只是生成了代理對象，獲取使用session中的load的方法(在沒有改變lazy屬性為false的情況下)獲取到的也是代理對象，所以在上面這幾種場景下就是延遲載入。 二.理解立即載入的概念 當Hibernate從數 ...
  • MVC使用EntityFramework（EF）生成資料庫模型
    首先打開VS2013，新建Web項目mcc,使用MVC模板。 右擊引用，管理NuGet程式包，安裝EntityFramework。 在Model文件下新建類Employee，新增幾個屬性，比如：EmployeeId，FirstName，LastName，Salary。 引用using System. ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類