一 问题重现

    前面在减少.NET内存占用的一则实践中，和大家分享了在.NET中使用P/Invoke技术来调用C++编写的非托管代码的例子。虽然性能和内存占用还不错，但是在随后而来的几周里，在某些同事的机器上总是偶尔会出现异常导致应用程序突然崩溃，尤其是在一些配置比较好的机器上。于是完善了一下日志记录，捕捉到最多的异常是:

    “Attempted to read or write protected memory. This is often an indication that other memory is corrupt.”

    然后调试的时候无法跟进去，直接抛出如下的异常：

内存已损坏

    根据这个异常实在查找不出任何有意义的信息，不过结合这两者很明显的知道，问题出在调用的非托管的代码里面。

二 解决方法

    根据之前提示的问题，在Google里面查了一下，发现了一篇文章P/Invoke and memory related issues 该文章指出：由于.NET对内存崩溃异常敏感，所以P/Invoke最容易出现内存异常的问题。出现“Attempted to read or write protected memory. This is often an indication that other memory is corrupt”问题的很大一部分原因是P/Invoke非托管代码导致的，有两种情况下很容易出现：

  • 传进去了错误的指针。
  • 在非托管内部代码中有异常，或者在方法内部对内存存在错误访问。

    在程序中往非托管方法传进去参数的时候，都是以String作为参数的，返回值是以StringBuilder作为类型在参数里面带出来的，函数的返回值指示方法的执行成功与否。传进去的值是没有问题，传出的值的StringBuilder在开始调用的时候，也已经分配了足够大的空间。

    所以就开始看是否是在非托管代码里面是否出了异常，于是开始在C++对每个方法对进行了try catch看能否捕捉到异常，并尝试恢复，不让应用程序挂掉，但是发现C++中的异常处理并不是像.NET中的那样，出现了内存已损坏的问题，从中恢复很困难，导致程序直接崩溃。由于我对C++不太熟悉，很多方法都是我临时拿了本书看了下写的，所以为了彻底解决这一问题，去请教我们部门对C++比较懂的同事看了下，也没有发现什么问题。

挣扎了一会儿，最后想到是不是在并发的时候出了问题，因为这个异常很容易在连续请求的时候产生，也很容易在配置比较好的机器上产生。于是想着对方法的访问加锁。在一开始的时候，我想着在C++里面加了锁，后来想想，还不如直接在调用P/Invoke方法的地方加锁。于是，解决方法很简单，定义一个全局的锁

public static volatile object SecuLock = new object();

    然后在所有调用同一个非托管dll里面方法的地方都加锁，然后问题就解决了。

lock (SeverCallBack.SecuLock)
{
    EMGFindSecu("300",result);
}

三 问题的原因

    由于我在非托管的dll中，定义了一个全局的集合变量，然后多个方法都会对这个全局的变量进行查询或者修改等操作，在某些特定情况下，会发生同一个dll中的两个非托管方法会被同时调用的问题，这样这两个方法会同时操作一个集合对象，这时就会在C++中抛出如上异常，该异常捕捉到之后，似乎不太好恢复，所以会直接到导致应用程序出现崩溃。所以大家在应用P/Invoke的时候，如果出现如上的异常信息，不防对非托管dll方法中有可能对同一集合对象进行操作的方法加锁，在某一时刻，只允许这些方法中的一个方法对其进行操作。

    P/Invoke是.NET的一个很强大的特性，他使得我们能够高效的和非托管代码进行互操作，并且很容易使用，但是在使用的过程中也很容易出现异常，这些异常不仅难以处理和恢复，在大多数情况下会直接使得我们的应用程序崩溃。希望本文对您在.NET P/Invoke中遇到类似问题能够提供一些帮助。