我最近正在使用一个DateTime对象,并写了这样的东西:

DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?

AddDays()的智能感知文档说它在日期后添加了一天,但它并没有这样做——它实际上返回了一个添加了一天的日期,所以你必须这样写:

DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date

这个问题以前已经困扰过我很多次了,所以我认为将最糟糕的c#陷阱分类会很有用。


当前回答

内存泄漏,因为您没有取消关联事件。

这甚至让我认识的一些高级开发人员被发现了。

想象一个WPF表单,里面有很多东西,你在其中的某个地方订阅了一个事件。如果您不取消订阅,那么关闭和取消引用后,整个表单将保留在内存中。

我相信我看到的问题是在WPF表单中创建一个DispatchTimer并订阅Tick事件,如果你不对计时器做-=,你的表单泄漏内存!

在本例中,您的拆卸代码应该具有

timer.Tick -= TimerTickEventHandler;

这一点特别棘手,因为您在WPF表单中创建了DispatchTimer实例,所以您会认为它是一个由垃圾收集进程处理的内部引用……不幸的是,DispatchTimer在UI线程上使用了一个静态的订阅和服务请求的内部列表,所以引用是由静态类“拥有”的。

其他回答

不是最糟糕的,但还没被提起。工厂方法作为参数传递给System.Collections.Concurrent方法可以被多次调用,即使只使用了一个返回值。考虑到. net在线程原语中多么强烈地试图保护您不受虚假唤醒的影响,这可能会让您感到惊讶。

using System;
using System.Collections.Generic;
using System.Collections.Concurrent;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ValueFactoryBehavingBadlyExample
{
    class Program
    {
        static ConcurrentDictionary<int, int> m_Dict = new ConcurrentDictionary<int, int>();
        static ManualResetEventSlim m_MRES = new ManualResetEventSlim(false);
        static void Main(string[] args)
        {
            for (int i = 0; i < 8; ++i)
            {
                Task.Factory.StartNew(ThreadGate, TaskCreationOptions.LongRunning);
            }
            Thread.Sleep(1000);
            m_MRES.Set();
            Thread.Sleep(1000);
            Console.WriteLine("Dictionary Size: " + m_Dict.Count);
            Console.Read();
        }

        static void ThreadGate()
        {
            m_MRES.Wait();
            int value = m_Dict.GetOrAdd(0, ValueFactory);
        }

        static int ValueFactory(int key)
        {
            Thread.Sleep(1000);
            Console.WriteLine("Value Factory Called");
            return key;
        }
    }
}

(可能)输出:

Value Factory Called
Value Factory Called
Value Factory Called
Value Factory Called
Dictionary Size: 0
Value Factory Called
Value Factory Called
Value Factory Called
Value Factory Called

我一直认为值类型总是在堆栈上,引用类型总是在堆上。

但事实并非如此。当我最近在SO上看到这个问题时(可以说回答是错误的),我才知道事实并非如此。

正如Jon Skeet的回答(引用Eric Lippert的博客文章),这是一个神话。

相当重要的环节:

关于值类型的真相

引用不是aAddress

堆栈是实现细节第1部分

堆栈是实现细节第2部分

讨厌的Linq缓存抓到了你

看看我的问题导致了这个发现,以及发现这个问题的博主。

简而言之,DataContext保存了你曾经加载过的所有Linq-to-Sql对象的缓存。如果其他人对您之前加载的记录进行了任何更改,则您将无法获得最新数据,即使您显式地重新加载该记录!

这是因为DataContext上有一个名为ObjectTrackingEnabled的属性,默认为true。如果您将该属性设置为false,则记录将每次重新加载…但是…你不能使用SubmitChanges()持久化对该记录的任何更改。

明白了!

MemoryStream.GetBuffer() vs MemoryStream.ToArray()。前者返回整个缓冲区,后者只返回使用的部分。讨厌的东西。

在调试环境中求值时,base关键字不能按预期工作:方法调用仍然使用虚拟分派。

当我偶然发现它时,我浪费了很多时间,我以为我遇到了CLR时空中的某种裂缝,但我后来意识到这是一个已知的(甚至有点故意的)bug:

http://blogs.msdn.com/jmstall/archive/2006/06/29/funceval-does-virtual-dispatch.aspx