我有一个C# Windows服务，最近将其从.NET 3.5迁移到了.NET 4.0，没有做任何其他代码更改。
在运行时使用3.5时，给定工作负载的内存利用率大约为1.5 GB，吞吐量为每秒20个X（在此问题的上下文中，X并不重要）。
完全相同的服务在4.0上运行时，内存使用量在3GB到5GB+之间，并且每秒钟只有不到4个X。实际上，该服务通常会因为内存使用量不断增加而停止响应，直到我的系统占用率达到99％，页面文件交换疯狂。
我不确定这是否与垃圾收集有关，但我很难找出原因。我的窗口服务通过下面配置文件中的开关使用“服务器”GC：
<runtime>
<gcServer enabled="true"/>
</runtime>
将这个选项更改为 false 似乎没有任何区别。此外，根据我在 4.0 中新 GC 的阅读，大的变化只影响工作站 GC 模式，而不是服务器 GC 模式。因此，也许 GC 和问题无关。
有什么想法？
这是一个有趣的问题。
根本原因是SQL Server Reporting Services的LocalReport类（v2010）在.NET 4.0上运行时的行为发生了变化。
基本上，微软改变了RDLC处理的行为，使每次处理报表都在一个单独的应用程序域中进行。 实际上，这是为了解决由于无法从应用程序域卸载程序集而引起的内存泄漏。 当LocalReport类处理RDLC文件时，它实际上会动态创建一个程序集并将其加载到应用程序域中。
在我的情况下，由于我正在处理大量的报表，这导致创建了大量的System.Runtime.Remoting.ServerIdentity对象。 这是导致问题的提示，因为我不明白为什么处理RLDC需要远程调用。
当然，要调用另一个应用程序域中类的方法，远程调用正是您要使用的方法。 在.NET 3.5中，这是不必要的，因为默认情况下，RDLC程序集将加载到同一应用程序域中。 然而，在.NET 4.0中，默认情况下会创建一个新的应用程序域。
修复很简单。首先，我需要使用以下配置启用传统安全策略：
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true"/>
</runtime>
接下来，我需要通过调用以下代码强制RDLC在与我的服务相同的应用程序域中进行处理：
myLocalReport.ExecuteReportInCurrentAppDomain(AppDomain.CurrentDomain.Evidence);
这解决了问题。
我遇到过这个确切的问题。而且应用程序域是被创建而不是清理的事实是正确的。然而，我不建议回退到传统方式。它们可以通过ReleaseSandboxAppDomain()进行清理。
LocalReport report = new LocalReport();
...
report.ReleaseSandboxAppDomain();
我还做了其他一些清理工作：
取消订阅任何SubreportProcessing事件， 清除数据源， 销毁报告。
我们的Windows服务每秒钟处理多个报告，没有泄漏。
我来晚了，但是我有一个真正的解决方案，并可以解释为什么！
事实证明，这里的LocalReport正在使用.NET Remoting动态创建子应用程序域并运行报表，以避免内部某处的泄漏。然后我们注意到，最终，报表将在10到20分钟后释放所有内存。对于需要生成大量PDF的人来说，这是不可行的。然而，关键在于它们正在使用.NET Remoting。 Remoting的关键部分之一是称为“租赁”的东西。租赁意味着它将保留那个Marshal对象一段时间，因为Remoting通常昂贵且可能会被多次使用。LocalReport RDLC正在滥用这一点。
默认情况下，租约时间为... 10分钟！此外，如果某些东西对其进行了多次调用，则会将另外2分钟添加到等待时间中！因此，它可能随机介于10到20分钟之间，具体取决于调用的排列方式。幸运的是，您可以更改此超时发生的持续时间。不幸的是，您只能在每个应用程序域中设置一次...因此，如果您需要除PDF生成之外的远程操作，则可能需要运行另一个服务来运行它，以便可以更改默认值。要做到这一点，您只需要在启动时运行以下4行代码：
LifetimeServices.LeaseTime = TimeSpan.FromSeconds(5);
LifetimeServices.LeaseManagerPollTime = TimeSpan.FromSeconds(5);
LifetimeServices.RenewOnCallTime = TimeSpan.FromSeconds(1);
LifetimeServices.SponsorshipTimeout = TimeSpan.FromSeconds(5);
你会看到内存使用量开始上升，然后在几秒钟内，应该会看到内存开始回归。我曾经用内存分析器花了几天时间来跟踪这个问题并意识到发生了什么。
你不能将ReportViewer放在using语句中（Dispose会崩溃），但如果你直接使用LocalReport，应该可以。之后释放它，如果你想确保尽一切可能释放内存，可以调用GC.Collect()。
希望这可以帮助到你！
编辑
显然，在生成PDF报告后，你应该调用GC.Collect(0)，否则似乎内存使用量仍可能很高，原因不明。
为了完整起见，如果有人正在寻找等效的 ASP.Net web.config 设置，则为：
<system.web>
<trust legacyCasModel="true" level="Full"/>
</system.web>
ExecuteReportInCurrentAppDomain 的功能与之相同。
感谢这个社交MSDN参考文献。
const string sReportsProgram = "SomethingReports.exe";
public static void RunReport1(DateTime pDate, int pSomeID, int pSomeOtherID) {
RunWithArgs(ReportType.Report1, pDate, pSomeID, pSomeOtherID);
}
public static void RunReport2(int pSomeID) {
RunWithArgs(ReportType.Report2, pSomeID);
}
// TODO: currently no support for quoted args
static void RunWithArgs(params object[] pArgs) {
// .Join here is my own extension method which calls string.Join
RunWithArgs(pArgs.Select(arg => arg.ToString()).Join(" "));
}
static void RunWithArgs(string pArgs) {
Console.WriteLine("Running Report Program: {0} {1}", sReportsProgram, pArgs);
var process = new Process();
process.StartInfo.FileName = sReportsProgram;
process.StartInfo.Arguments = pArgs;
process.Start();
}
[STAThread]
static void Main(string[] pArgs) {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
var reportType = (ReportType)Enum.Parse(typeof(ReportType), pArgs[0]);
using (var reportForm = GetReportForm(reportType, pArgs))
Application.Run(reportForm);
}
static Form GetReportForm(ReportType pReportType, string[] pArgs) {
switch (pReportType) {
case ReportType.Report1: return GetReport1Form(pArgs);
case ReportType.Report2: return GetReport2Form(pArgs);
default: throw new ArgumentOutOfRangeException("pReportType", pReportType, null);
}
}
GetReportForm方法应该获取报表定义，使用相关参数获取数据集，将数据和任何其他参数传递给报表，然后将报表放置在表单上的报表查看器中并返回对该表单的引用。请注意，可以提取此过程的大部分内容，以便您基本上可以说“使用此数据和这些参数从此程序集为此报表提供一个表单”。
BlockingCollection或ConcurrentQueue类？ConcurrentQueue存在内存泄漏问题，可能是一个问题所在。 - Jim MischelConcurrentQueue在 .NET 的并行扩展中是存在的。从 3.5 转换到 4.0 可能涉及将其替换为System.Collections.Concurrent。我知道我们在转换到 4.0 时做了这件事。 - Jim Mischel