gnodet-bot commented on code in PR #12695:
URL: https://github.com/apache/maven/pull/12695#discussion_r4051118845
##########
impl/maven-core/src/main/java/org/apache/maven/internal/impl/DefaultSession.java:
##########
@@ -63,6 +65,7 @@ public class DefaultSession extends AbstractSession
implements InternalMavenSess
private final MavenRepositorySystem mavenRepositorySystem;
private final RuntimeInformation runtimeInformation;
private final Map<String, Project> allProjects = new ConcurrentHashMap<>();
+ private BuildEnvironment buildEnvironment;
Review Comment:
**[Medium] Non-volatile lazy-init field on a `@ThreadSafe` class — data
race.**
`Session` is annotated `@ThreadSafe`. `DefaultSession.buildEnvironment` is a
plain `private` field with a non-atomic lazy-init pattern:
```java
if (buildEnvironment == null) {
buildEnvironment =
BuildReportCollector.buildEnvironment(getMavenSession());
}
return buildEnvironment;
```
Under the Java Memory Model, a write to a non-`volatile` field by thread A
is not guaranteed to be visible to thread B. Two threads calling
`session.buildEnvironment()` concurrently before the field is initialized can
each see `null`, each compute a distinct `DefaultBuildEnvironment`, and each
write their own — leaving the field in a state where different threads see
different instances. This is exactly why `BuildReportCollector` correctly
declares its counterpart field `private volatile BuildEnvironment
buildEnvironment`.
Note: for this to be data-race-free, either use `volatile` (JMM guarantees
visibility) or synchronize. Since `DefaultBuildEnvironment` is an immutable
record, multiple initializations produce equivalent objects — but the racy
read/write still constitutes a data race under JMM, which is undefined behavior
regardless of whether the result is logically correct.
```suggestion
private volatile BuildEnvironment buildEnvironment;
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
