Java 메모리 모델 (1.5 이후)은 final 필드를 final 필드와 다르게 처리합니다. 특히, 건설 중에 참조가 벗어나지 않는 경우, 생성자의 final 필드에 대한 쓰기가 다른 스레드에서 데이터 경합을 통해 다른 스레드에서 사용 가능하게 되어도 다른 스레드에서 볼 수 있도록 보장됩니다. 비 final 필드에 대한 쓰기는 표시되지 않을 수 있으므로 부적절하게 게시하면 다른 스레드가 부분적으로 구성된 상태에서 해당 스레드를 볼 수 있습니다.스칼라 및 Java 메모리 모델
Scala 컴파일러가 생성하는 방법/final (final이 아닌) 클래스 용 백업 입력란이 있습니까? 언어 사양을 살펴본 후 웹을 검색했지만 확실한 답을 찾을 수 없습니다. 당신이 val로 뭔가를 선언 할 때 그것은 final 필드를 만듭니다
나는 변경이되었을 때 알아 내기 위해 역사를 통해 파고도 최종 필드가 포함되어 있다는 것을 의미한다.
은 JVM에 스칼라의 투사가 언어 사양이 적용되지 않습니다.
(비교에서 @scala.volatile 주석 는 volatile로 필드를 표시하는 문서화입니다). var과 같이 참조를 수정할 수있는 것은 모두 final이 될 수 있습니다 (분명히).
이 case classes가 (이 경우 클래스 생성자의 인수로 암시 적으로 val들입니다)
예전처럼 생각하지 않았습니다. (예 : http://old.nabble.com/Val-and-Final-td13355515.html 참조). 내 질문에 대한 이유 중 일부 - 문서없이 변경 될 수있는 경우 다시 변경되지 않는다는 것을 어떻게 알 수 있습니까? –
이 내용이 문서화되어 있어야합니다. 이것은 단순히 성능의 문제가 아니라 메모리 모델로 인해 언어 자체의 일부입니다. val이 non-final이라는 사실을 알지 못했습니다. –
Scala bug 시스템에이 문제에 대한 문서 버그를 제출했습니다.
하지만 동시성 관점에서 볼 때 언어 구조의 동작은 논쟁의 여지가 있습니다. –