针对你遇到的日志密集型服务添加多个Async File Target后出现死锁的问题，结合你的NLog配置和环境（NLog 4.4.11/4.5.4，.NET 4.5），我整理了以下分析和解决方案：

可能的死锁原因分析 #

• 异步包装器的无间隙批量处理：你的两个AsyncWrapper都设置了timeToSleepBetweenBatches="0"，这意味着异步线程会持续不断地处理日志批量，没有任何休息时间。在高并发日志场景下，线程会一直占用CPU和线程池资源，容易引发线程竞争和锁等待，最终导致死锁。同时overflowAction="Grow"让队列无限制增长，进一步加剧了资源消耗。
• 文件目标的IO锁竞争：两个File Target都写入同一个根目录（${gdc:item=rootPath}）及其子目录，即使文件名不同，文件系统的目录级锁或NLog内部的文件监控逻辑也可能引发锁竞争。加上autoFlush="True"会强制每次写入都刷新到磁盘，高并发下IO操作的阻塞会放大锁竞争的概率。
• NLog旧版本的已知问题：NLog 4.x早期版本（包括4.4.11和4.5.4）在AsyncWrapper的线程调度和锁处理上存在一些缺陷，尤其是在多异步目标并发处理时，容易出现死锁情况。

具体解决方案 #

1. 调整AsyncWrapper的参数配置 #

修改每个AsyncWrapper的以下参数，缓解线程竞争：

• 添加timeToSleepBetweenBatches="10"：给异步线程设置短暂的休息时间，避免持续抢占资源。
• 设置queueLimit="5000"：限制队列的最大长度，防止内存溢出，同时减少线程等待队列的压力。
• 可选：添加workerThreads="2"：指定每个AsyncWrapper的工作线程数，避免线程池过度占用。

修改后的AsyncWrapper示例：

<target type="AsyncWrapper" name="asyncFile" overflowAction="Grow" timeToSleepBetweenBatches="10" batchSize="1000" queueLimit="5000" workerThreads="2">
  <!-- 内部File Target配置 -->
</target>

2. 优化File Target的IO配置 #

• 将autoFlush="True"改为autoFlush="False"：让NLog批量刷新日志到磁盘，减少频繁的IO操作，降低锁竞争概率。
• 若使用NLog 4.5+，添加ConcurrentWrites="true"：优化多线程写入的锁机制，减少文件系统层面的锁竞争。

修改后的File Target示例：

<target name="file" type="File" fileName="${gdc:item=rootPath}\${machinename}.${gdc:item=appName}.log" 
        archiveNumbering="Sequence" archiveAboveSize="10485760" maxArchiveFiles="10" 
        archiveFileName="${gdc:item=rootPath}\Archives\${machinename}.${gdc:item=appName}.{#}.log" 
        autoFlush="False" ConcurrentWrites="true">
  <!-- 布局配置 -->
</target>

3. 升级NLog到最新稳定版本 #

NLog后续版本（如4.6.x及以上）针对异步目标的死锁问题进行了修复，建议升级到最新的稳定版本，很多旧版本的锁竞争问题在新版本中已得到解决。

4. 排查死锁的具体细节 #

如果上述调整后问题仍存在，可以通过以下方式定位死锁根源：

• 使用Visual Studio的诊断工具捕获进程快照，查看死锁线程的调用栈，确认是NLog内部锁还是文件系统锁导致的。
• 查看你已开启的NLog内部日志（c:\Temp\nLog.txt），里面的锁等待或异常信息能帮助你更精准地定位问题。

内容的提问来源于stack exchange，提问作者Jason Pease