2017-10-20 118 views
-2

假設我想在很多線程上執行一些命令。我有這個示例代碼:C#繼續/破解內存泄露

for (int i = 0; i < 5000; i++) 
     { 
      new Thread(() => 
      { 
       while (true) 
       { 
        string foo = "foo " + DateTime.Now.Ticks; 

        bool breakout = false; 

        for (int j = 0; j < random.Next(10, 100); j++) 
        { 
         string bar = "bar " + DateTime.Now.Ticks; 
         if (j == 5) 
         { 
          continue; 
         } 
         if (j == 8) 
         { 
          breakout = true; 
          break; 
         } 
        } 

        if (breakout) 
        { 
         continue; 
        } 

        string baz = "baz " + DateTime.Now.Ticks; 
       } 
      }).Start(); 
     } 

這個代碼示例,創建5K線程和設置一些字符串,泄漏內存就我而言。隨着代碼的運行,內存使用率越來越高。 現在,我認爲這是因爲我設置變量,然後放棄它們 - 有沒有一種方法可以繼續/中斷內存使用增加越來越多?

+1

您正在創建5000個永不終止的線程。你正在泄漏記憶。 –

+4

你的頭銜似乎「怪」打破/繼續。你不認爲「運行5000個不斷創建新字符串的線程」更可能是原因嗎? (我的猜測是你的CPU太重,GC沒有機會運行。) –

+1

'if(j == 5)continue;'不需要部分,因爲沒有其他代碼會無論如何運行 - 無論如何循環將繼續。 –

回答

-4

這是一個經典的issue,它將一個字符串中的字符串連接成「+」字符。在循環中使用StringBuilder來組合字符串。

+0

似乎沒有任何字符串連接(特別是)會泄漏內存的問題。所有字符串只被分配一次,並且在每次迭代時超出範圍(因此成爲GC的候選人)。可能更有可能的是,只有連續創建字符串才能在收集內容之前填充內存。 –

+0

大概,但另一個問題是如果垃圾回收時間保證或瞬間 – numbtongue

+0

每次迭代連接一個字符串的無限循環肯定會造成無限的內存消耗。但切換到'StringBuilder'不會解決這個問題。你提到的「經典問題」涉及_speed_性能,而不是內存性能,因爲字符串連接不如使用StringBuilder那樣高效。兩者最終都會導致相同的_memory_消耗。在任何情況下,OP都不會重複連接相同的字符串,因此甚至不會遇到速度性能問題字符串連接的原因。 –