由于竞争条件，Spring 循环引用错误会随机发生吗? [英] Can Spring circular reference errors happen randomly due to race conditions?

问题描述

我们有一些构建因此错误的变体而失败:

We have some builds that are failing with variations of this error:

Error creating bean with name 'cartServiceImpl': Unsatisfied dependency expressed through field 'addressServiceClient'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'addressServiceClient': Bean with name 'addressServiceClient' has been injected into other beans [addressInfoServiceImpl] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.

问题是，当我们在桌面上启动服务时，我们永远不会看到这个错误.我们只在 CI 服务器上运行构建时看到此错误.实际上，大多数情况下，当我们构建相同的代码时，不会发生此错误.我有一个测试用例，它运行同一分支的四个并发构建并提交(目标是部署到四个不同的集群)，有时所有四个都成功，但有时其中一个(甚至两个)会因此错误而失败.

The thing is, we never see this error when we start up the service on our desktops. We only see this error when the build runs on the CI server. In fact, most of the time when we're building the same code, this error does not occur. I have a test case where it runs four concurrent builds of the same branch and commit (targeting for deployment to four different clusters), and sometimes all four succeed, but sometimes one (or even two) of them will fail with this error.

当我确定这似乎是随机的时，我的第一个理论是，我们的 docker 注册表或 docker 缓存存在一些棘手的问题，这有时会以某种方式为我们提供较旧的图像(存在这种性质的相关问题，几周前是真的).尽管我希望将其挂在另一支车队上，但我必须假设我们正在做的某些事情可能会导致这种情况，但这可能是随机的，因为这取决于比赛条件.我发现很难相信 Spring bean 解析会存在竞争条件.

My first theory, when I determined the seeming randomness of this, was that there was some screwy problem with our docker registry or docker cache, which was somehow occasionally giving us an older image (there was a related problem of this nature, for real, several weeks ago). Despite my desire to hang this on another team, I have to assume that there's something we're doing that could be causing this, but perhaps it's random because this is depending on a race condition. I find it hard to believe that Spring bean resolution could have race conditions.

是否有可能发生或不发生这样的错误，具体取决于竞争条件?

Is there any possibility that an error like this might occur or not occur, depending on race conditions?

我们使用的是 Spring Framework 5.0.9 和 Spring Boot 2.0.5.

We're using Spring Framework 5.0.9 with Spring Boot 2.0.5.

更新:

请注意，我仍然无法在我的笔记本电脑上通过普通测试重复这个问题，但是我们能够提取CI服务器上构建的jar文件并将其下载到我的笔记本电脑，然后直接运行，它确实可以得到同样的错误.我们比较了那个 jar 和一个好"的 jar 文件的内容，差异很微妙，没有明显的问题可能导致这种情况.我们确实注意到错误中提到的 AddressServiceClient 在坏"jar 中的类列表中排在第二位，在好"jar 中的列表中排在第二位.

Note that I still can't repeat this problem with ordinary testing on my laptop, but we were able to extract the jar file constructed on the CI server and download it to my laptop, and then run that directly, and it does get the same error. We compared the contents of the jar file between that jar and a "good" one, and the differences were subtle, no obvious problems that might cause this. We did notice that the AddressServiceClient mentioned in the error is second in the list of classes in the "bad" jar, and far down the list in the "good" jar.

然后我想也许将 @Lazy 添加到 AddressServiceClient 类可以避免这个问题(不是我不说修复").我尝试在本地修改那个坏"的 jar 文件，使用zip"用更新的类文件更新 jar 文件，我发现生成的 jar 文件没有表现出症状.但是，当我最终将 PR 与此更改合并并在 CI 服务器上运行构建时，其中一个仍然失败并出现相同的错误.

I then thought that perhaps adding @Lazy to the AddressServiceClient class would avoid the problem (not that I don't say "fix"). I tried modifying that "bad" jar file locally, using "zip" to update the jar file with the updated class file, and I found that that resulting jar file did NOT demonstrate the symptom. However, when I finally merged the PR with this change and the builds ran on the CI server, one of them still failed with the same error.

推荐答案

可以使用 setter 注入，它使用 Spring L3 Cache.
例如:

You can use setter injection, it use Spring L3 Cache.
For example:

    private TmsOrderService tmsOrderService;

    @Autowired
    public void setTmsOrderService(TmsOrderService tmsOrderService) {
        this.tmsOrderService = tmsOrderService;
    }

Spring L3 Cache 避免循环依赖.

Spring L3 Cache avoid circular dependencies.

这篇关于由于竞争条件，Spring 循环引用错误会随机发生吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！