我发现人声称，使用类中的所有只读域并不一定会使该类的实例不可变的，因为有办法甚至在初始化（建设中）来更改只读域值。

I have found that People claim that using all readonly fields in a class does not necessarily make that class's instance immutable because there are "ways" to change the readonly field values even after initialization (construction).

如何？什么办法呢？

我的问题是，当我们真的可以在C＃中的真正的不可变对象，我可以在线程安全地使用？

So my question is when can we really have a "real" immutable object in C#, that I can safely use in threading?

也不要匿名类型创建不可改变的对象？有人说，LINQ使用一成不变的objecst内部。究竟如何？

Also do anonymous types create immutable objects? And some say LINQ uses immutable objecst internally. How exactly?

推荐答案

您已经问这样五个问题在那里。我来回答第一个：

You've asked like five questions in there. I'll answer the first one:

有类中的所有只读域并不一定会使该类的实例不可变的，因为有办法，即使施工后改变只读域值。怎么样？

Having all readonly fields in a class does not necessarily make that class's instance immutable because there are "ways" to change the readonly field values even after construction. How?

是否有可能施工后改变一个只读字段？

Is it possible to change a readonly field after construction?

是，如果你足够信任的打破只读岬的规则。

是如何工作的？

用户存储在你的过程中的每一位是可变的。像只读域约定可能会使某些位似乎是不可改变的，但是如果你试图够硬，你可以变异他们。例如，你可以把一个不可变对象实例，获取其地址，并直接改变原位。这样做可能需要大量的聪明和内存管理器的内部实现细节的知识，但不知何故，在内存管理器管理变异内存，这样你就可以过，如果你足够努力。您还可以使用私有反思突破安全系统的各个部分，如果你充分信任的。

Every bit of user memory in your process is mutable. Conventions like readonly fields might make certain bits appear to be immutable, but if you try hard enough, you can mutate them. For example, you can take an immutable object instance, obtain its address, and change the raw bits directly. Doing so might require a great deal of cleverness and knowledge of the internal implementation details of the memory manager, but somehow the memory manager manages to mutate that memory, so you can too if you try hard enough. You can also use "private reflection" to break various parts of the safety system if you are sufficiently trusted.

根据定义，完全信任的code被允许突破安全系统的规则。这就是完全信任的意思。如果你完全信任code选择使用像私人反射或不安全code工具打破了内存的安全规则，完全受信任的code是允许这样做。

By definition, fully trusted code is allowed to break the rules of the safety system. That's what "fully trusted" means. If your fully trusted code chooses to use tools like private reflection or unsafe code to break the memory safety rules, fully trusted code is allowed to do that.

请不要。这样做是危险和混乱。存储安全系统的设计，使其更容易来思考你的code的正确性;故意违反它的规则是一个坏主意。

Please don't. Doing so is dangerous and confusing. The memory safety system is designed to make it easier to reason about the correctness of your code; deliberately violating its rules is a bad idea.

那么，是只读的谎言？好吧，假设我告诉你的如果每个人都遵守规则的，每个人都得到蛋糕一片。是蛋糕的谎言？这种说法是的没有的索赔，你会得到一块蛋糕。就是这样的的要求，如果每个人都遵守规则的，你会得到一块蛋糕。如果有人作弊，并把你的一片，没有蛋糕为您服务。

So, is "readonly" a lie? Well, suppose I told you that if everyone obeys the rules, everyone gets one slice of cake. Is the cake a lie? That claim is not the claim "you will get a slice of cake". That's the claim that if everyone obeys the rules, you'll get a slice of cake. If someone cheats and takes your slice, no cake for you.

是一类只读只读领域？是的，但只有当每个人都遵守规则。因此，只读字段不是骗人的。该合同是，如果每个人都遵从系统然后该字段观察到只读的规则。如果有人打破了规则，那么也许它不是。这不作陈述，如果每个人都遵守规则，该字段为readonly骗人的！

Is a readonly field of a class readonly? Yes but only if everyone obeys the rules. So, readonly fields are not "a lie". The contract is, if everyone obeys the rules of the system then the field is observed to be readonly. If someone breaks the rules, then maybe it isn't. That doesn't make the statement "if everyone obeys the rules, the field is readonly" a lie!

你也没问，但也许应该有一个问题，无论是在结构领域只读，是一个谎言为好。请参阅Does利用公共只读字段不可变结构的工作？对这个问题的一些想法。在结构只读域是更骗人的不是一类只读域。

A question you did not ask, but perhaps should have, is whether "readonly" on fields of a struct is a "lie" as well. See Does using public readonly fields for immutable structs work? for some thoughts on that question. Readonly fields on a struct are much more of a lie than readonly fields on a class.

至于你的问题，其余的 - 我想如果你问每个问题一个问题，而不是每个问题五个问题，你会得到更好的效果

As for the rest of your questions -- I think you'll get better results if you ask one question per question, rather than five questions per question.