重大发现（愚以为）！深拷贝与同步互斥的异曲同工

Question

今天写了个测试程序，发现在不同线程中调用同一个函数时，如果参数是引用类型（数组实例），数组会被相互干扰。
我的解决方法：
   1：同步互斥：经典的四种方法（加锁、互斥量、符号、信号） 这就不说了
   2：深拷贝：
     public class tool1:ICloneable
实现接口 
        #region ICloneable 成员        public object Clone()
        {
            tool1 newSession = new tool1(n);
            newSession.n = n;//
            return newSession;
            //throw new Exception("The method or operation is not implemented.");
        }        #endregion
我的测试结果是：
   2种方法都可实现，但是同步互斥是比较浪费时间的。
     深拷贝是比较浪费空间，但是速度很快。欢迎大家指正，是不是有什么没有考虑到。

Answer 1

微软的string类型就是楼主这样处理的.
当然是线程安全,但是.....

Answer 2

string类型在c#中本身就是值类型，而不是引用。

Answer 3

我基本同意这种说法。有些资料，甚至微软为了推销F#的文档，鼓吹什么拷贝可以解决同步问题。纯粹是自欺欺人。为什么会产生“相互干扰”现象？不外乎两种原因：
1. 根本不应该修改对象。那么你需要测试系统来发现修改对象的逻辑bug，这样就是不用拷贝也不会出错，因为你的程序并不会修改对象。2. 运行中必须实时修改对象，来同步多个业务逻辑的执行次序。那么所谓深拷贝系统就完蛋了。
所以，我们需要的是一个测试系统可以在实际发布系统之前就测试出所谓线程不安全，或者有（类似于微软正在研究而没有发布的一些系统）对内存进行可靠的类似数据库事务的保护（编程要求很少）。在复杂的系统中拼命地地拷贝大量环境数据放到堆栈上，可能只能算作一个比较学术的做法。

Answer 4

楼主这番思考的精神值得赞扬不过就事论事的说，想歪了深拷贝用作线程互斥的解决方案本身有点南辕北辙另外，string在C#中是引用类型，而非值类型，仅仅是用起来“像”是值类型一样

Answer 5

你可真是个热心人，上次c/s系统的负载预测就是有你的解说和推断，最后越来越清晰。
我这里的问题主要是多线程中单个线程多次接收数据，如果接收太快，上次还未处理，数据就被覆盖了，我不想这样，系统其实不会这么频繁接收，所以没有使用缓冲区，而是直接覆盖数据，所以我想用深拷贝把未处理的处理，而这样即使新来的数据很快到来，会有新的事件触发，再次处理。
   当然这里有个问题，就是如果tcp本身粘包那我可能就没办法了，但是我的程序中数据处理需要时间相对长一些，所以我担心的是旧数据被新数据覆盖。

Answer 6

同步问题是为了解决访问"同一个对象"造成的数据不完整.copy就是copy, 为了获得"多个对象".
这两个怎么会扯在一块了?

Answer 7

一个浪费时间 ，一个浪费空间，
要不弄成静态的？省的new，不过弊端也很大。。