对于哪些类型的变量绝不能是静态的？答案

【问题标题】：For what types variables must never be static?对于哪些类型的变量绝不能是静态的？
【发布时间】：2010-12-01 14:20:39
【问题描述】：

在我们项目中大量使用的一个库中，有一个限制，即其类的变量不能是静态的。（它是ULC）。据我了解，这是因为需要将它们全部序列化。这条规则的问题在于它并不严格，并且可能是难以调试的错误的原因。

我们将为 Checkstyle 编写一个模块来检测这种类型的静态变量（可能由一些可定制的正则表达式检测到）。我们需要知道这项检查对其他开发人员来说有多么必要。

所以问题是：某些类型的变量绝不能是静态的一般情况是什么？

【问题讨论】：

你是说变量吗？没有“静态实例”这样的概念。

标签： java static checkstyle

【解决方案1】：

首先，正确的面向对象设计应告知将方法/字段设为静态的决定。

其次，在 Web 应用程序中，请求都在单独的线程上处理，您必须非常小心如何使用静态方法/字段。如果您的静态方法在调用中保持任何状态（例如，通过使用静态字段来保持计数），您可能会遇到线程问题。发生这种情况是因为一个请求可能会调用静态方法，然后在执行过程中被另一个调用该方法的线程停止。如果第一次调用修改了一个公共资源，但没有完成，那么第二次调用可能会破坏第一次执行的进度。

【讨论】：

我同意，但实际上正确的 OOA/OOD 要求您从不使用 Java 特有的 static。它在 OOA/OOD 级别不存在，并且使用语言的特质而不是正确的翻译始终是 OOA/OOD -> OOP 翻译错误。有人可能认为他需要 Java 的静态，但实际上不需要：任何 OOA/OOD 都可以在没有 EVER 的情况下使用 static 关键字转换为 Java。就像任何 OOA/OOD 都可以正确而干净地翻译成没有 static 概念的 OO 语言一样。

【解决方案2】：

简单的答案：如果一个类型会以线程不安全的方式被修改，那么它绝不能用作静态实例。我怀疑这就是 ULC 建议不要以这种方式使用它们的类型的原因（不是因为序列化）。

不幸的是，用 checkstyle 之类的东西检查这个是非常困难的。例如，HashMap 不是线程安全的。但是，如果我在类加载期间构造一个实例并静态填充它，然后只在之后从映射中读取，这是 HashMap 的安全用法（因为类加载在设置时提供了外部线程安全保证，并且之后永远不会修改） .

【讨论】：

据我了解，ULC 类型的静态变量的问题不在于并发。但是我认为 checkstyle 或类似的工具仍然可以用于这种情况。如果使用一些正则表达式指定了禁止静态类型的名称，那么我们可以禁止项目中的特定类型，这在大型开发团队中可能很有用。