Question

今天，我们在代码中找到了这种模式：

class Foo {
    private List<String> errors;

    public void addError(String error) { ... }
    public List<String> getErrors();
}

虽然代码似乎有用，但这是一个单独的Spring bean，并且它被注入了几个独立的地方，并且bean的使用者假设他们每个都有自己的错误列表。所以这会引入微妙的错误。

显而易见的解决方案是教育开发人员避免这种错误，但我想知道是否有静态或运行时代码分析工具可以找到这种错误。

例如，bean后处理器可以在返回之前分析bean，并查找不是@Autowired的私有字段。

Answer 1

在此之后倾注了更多的大脑（我们和其他人），我们提出了这种方法：

安装BeanPostProcessor，确保所有单例bean（即bean定义中的作用域为Singleton）在实际bean类型上具有自定义注释@Stateless

我们选择了自定义注释，而不是重复使用@Singleton，因为我们在其他地方也需要此功能。

如果缺少注释，工厂会抛出错误。
在单元测试中，我们使用带有自定义注释的ClassPathScanningCandidateComponentProvider来定位类路径上的所有类。然后我们可以进行复杂且昂贵的测试，以确保bean在初始配置之后没有状态发生变化（即在自动装配发生之后）。

如果我们将自动装配的字段移动到构造函数中，第二步可能会变得更容易，但我们不喜欢采用许多参数的方法。如果Java或IDE可以从bean代码生成构建器，那将是很好的。由于情况并非如此，我们坚持使用自动装配的字段和/或设置器。

Answer 2

您可以创建一个可以加载应用配置的JUnit测试。这可以从这里组合ListableBeanFactory：

点击'isSingleton'检查：

即。列出应用程序上下文中的所有bean，然后检查哪些是单例。

这可以让你找到所有的单身豆......虽然它不会真正阻止你的错误案例，有人将这些单身人士中的一个视为不是。