在 ASP.net 中使用静态方法进行安全验证是不明智的吗？

Question

我有一个像这样的静态方法

public static string DoSomethingToString(string UntrustedString)
{
//parse format and change string here.
return newString.
}

因为我知道多次调用：

static int myInt=0;
public static int AddNumber()
{
lock(someObject)
{
myInt++;
return myInt;    
 }
}

将返回一个不断增加的数字（在页面之间共享），我不确定在 DoSomethingToString() 中如何处理局部变量；

我想了解在 ASP.net 中可以安全/不安全地使用静态方法的条件，只是为了让我的多线程大脑专注于这个主题。

更新：

大部分讨论都是围绕值类型进行的。我如何知道何时可以安全地调用更改我的引用类型的方法（显式或隐式）？查看 MSDN 文档并仅使用“threadSafe”的方法就足够了吗？

如果我称之为隐式更改的一个示例是使用 String.Split()，因为它是同一类的一部分。我认为有可能共享一些安全特性，并且不需要担心/勤奋。 (?)

我所说的显式更改（因为现在没有更好的词）是调用另一种方法来工作……它可以是静态的或实例类。我认为需要做更多的背景/研究工作来确保每个对象和方法都是线程安全的。

为了便于讨论，假设我有一个带有这个签名的方法：

ValidateStringAndContext(string untrustedString, Object myCustomUserContext)

它有一个引用以下对象的静态方法

public SecurityChecker
{
public static object CheckSecurityStatic(string DirtyData)
{
//do string.split
//maybe call a database, see if it's a token replay 
//

//OR  - alternate implementation
SecurityChecker sc = new SecurityChecker();
 if (sc.CheckSecurity(DirtyData))
  {
  myCustomUserContext.Property1 = new GUID()
  }
return myCustomUserContext;
}


public class bool CheckSecurity(string DirtyData)
{
//do string.split
//maybe call a database, see if it's a token replay 
// return true if OK return false if not
}
}

修改后的问题

如果我创建的静态“实用程序”类要创建另一个对象的实例，然后调用方法——与直接调用静态方法相比，我会遇到并发问题（变量相互覆盖）吗？

Answer 1

每个调用静态方法的线程都有自己的调用堆栈。对 DoSomethingToString() 的每次调用都有自己的方法变量副本，完全独立于另一个线程上对该方法的任何其他调用（除非您将变量声明为静态，否则您可能会感到困惑 - 静态变量只有一个可供程序中多个线程访问的实例）。

与往常一样，当多个线程访问共享资源时，您需要考虑并发性。当资源仅存在于方法调用的上下文中时，并发性不是问题。

另请参阅：https://stackoverflow.com/questions/511378/net-static-methods-and-its-effects-on-concurrencyt

Answer 2

与问题中显示的代码相比，与不可见的代码有关的一些非常重要的点...

DoSomeThingToString 方法是静态的，在该方法中声明的任何变量都将是该线程调用堆栈的本地变量。如果正在使用的变量是在函数外部定义的，那么您将在该内存上出现竞争条件。确保它看起来像这样，只使用局部变量：

public static string DoSomethingToString(string UntrustedString)
{
    var newString = UntrustedString;
    // operations on newString...
    return newString;
}

AddNumber 方法可能会遇到其他可能不明显的问题。如果这真的是你想要做的，添加一个数字，这样做：

System.Threading.Interlocked.Increment(ref myInt);

Interlocked.Increment 方法保证操作将在一个时钟周期内完成。

否则，在极少数情况下使用 lock 关键字可能会很棘手。这里有一些经验法则。始终锁定一个您创建并持有其引用的对象，甚至更好的是，您永远无法更改该对象。这意味着：只读，并在创建类时分配内存地址。看起来像这样：

static int myInt=0;
static readonly object aGoodLock = new object();
public static int MoreComplexIntStuff()
{
    lock(aGoodLock)
    {
        // Do stuff with myInt...
    }
    return myInt;
}

此外，这还不是全部。另一个问题是，只要变量 myInt 被访问，即使它在这个类的另一部分 - 或者如果它是公共的并在其他地方使用，你需要用锁来包装它。而且不仅仅是任何锁，而是您使用的同一个锁，aGoodLock。

帮助您的开发人员（可能还有您自己的长期记忆）的最佳方法是制作变量和包装它的锁private，并使用您要小心的属性公开 myInt在 get 和 set 中使用锁。

Answer 3

我感觉您认为变量只能是实例变量或静态变量，而忘记了局部变量与两者不同。考虑：

public class MyClass
{
    public int InstanceInt;
    public static int StaticInt;
    public int InstanceMethod()
    {
        int i = new Random().Next(1, 50);
        return i;
    }
    public static int StaticMethod()
    {
        int j = new Random().Next(1, 50);
        return j;
    }
}

这里InstanceInt是一个实例变量，StaticInt是一个静态变量。如果它们要被不同的线程访问，这两者都需要锁定，但是，InstanceInt 只有在 MyClass 的实例被不同的线程访问时才会被不同的线程访问。这可能发生在static MyClass AllThreadsSeeMe = new MyClass()、存储在静态集合中、显式地将其传递给另一个线程等情况下，否则不会发生。同时，StaticInt 本质上可以被应用程序中运行的所有线程访问，即使您注意确保线程之间没有共享 MyClass 的实例。

同时，i 和 j 都是其函数的本地函数。每个调用该函数的线程都将获得自己的i 或j 副本，无论有多少线程可以调用它们。因此它们本质上是线程安全的。只有当这些方法中的任何一个更改静态或实例变量，或读取可以由不同方法更改的可变静态或实例变量时，它们才不是线程安全的（不可变的 - readonly - 变量也是线程安全的因为没有其他线程可以改变它们的值，因为根本没有线程可以改变它）。