并行化和線程

使代碼并行運行的最簡單，最可靠的方法是使用線程，因為在這種情況下，操作系統要處理所有任務切換和調度的復雜性，因此編程要容易得多。如果機器具有多個CPU，則OS甚至可以真正地并行運行多個線程，這是手動并行化的另一個重要優勢。程序員僅應注意適當的同步。

但是，假設該計算機只有一個CPU。然后，與微處理器系統相比，線程不能提高性能，特別是在每個線程需要100％的處理器時間的情況下，由于與順序程序相比上下文切換太頻繁，這將導致性能下降。

幸運的是，在掃描網絡的情況下，此問題極不可能發生：網絡通常比處理器慢得多。因此，處理每個數據包所花費的時間主要花費在等待第二方的響應上，從而使處理器能夠處理其他工作，這可能包括同時發送和等待其他數據包，與每個數據包的單獨處理時間之和相比，處理多個數據包所需的總時間要短得多。沒有線程，也可以借助異步套接字同時處理多個數據包。在某種程度上，他們甚至可以表現更好，但是，如果對結果進行了任何復雜的處理，并且調用了發送完全不同且不相關的數據包的第三方插件，則所有這些使線程的使用更加可靠，并且在編程方面更加容易。由于有了線程，每個訪存程序或插件的代碼可以是線性的，從而無需考慮其他訪存程序正在同時發送或接收的內容。眾所周知，在編程中良好的設計和代碼的簡化通常比略微提高性能更為重要，因為在任何情況下都非常需要質量和較低的維護成本。此外，編寫插件越容易，編寫的第三方插件就越多，從而對最終用戶產生積極影響。

不幸的是，用于掃描的線程數有實際限制。當上下文切換開始占用大量的處理器時間而不是執行實際工作時，就達到了限制。由于不同的操作系統實現不同的切換和調度算法，因此即使在同一硬件上運行，最大實際線程數在不同平臺上也不同。試驗顯示，在這方面，Microsoft操作系統要比免費系統遜色（例如Linux，BSD），而較舊的Windows版本（9X和ME）甚至不能以相同數量的線程處理用戶事件，而沒有明顯的影響在Linux上。

由于最大線程數可能會非常不同，因此默認情況下，Angry IP Scanner一次最多使用100個線程。如果用戶的硬件和軟件允許，則可以增加該數目，反之亦然。一些最新的組合甚至可以毫無問題地處理500個掃描線程，但是這個數目可能接近線程在掃描程序能夠通過啟動新線程達到極限之前完成其工作的情況。另一個限制可能是由于某些網絡適配器或其驅動程序（尤其是無線適配器）的不穩定性–它們無法同時處理這么多的同時連接或數據包，因此它們開始失去它們，使掃描結果不可靠。同樣的問題有時是人為造成的，主要是在Windows平臺上通過連接嘗試的速率限制，目的是防止很可能不幸進入系統的蠕蟲進行掃描。