2010-03-17 8 views
13

Модель памяти Java (начиная с версии 1.5) обрабатывает поля final по-разному полями не final. В частности, если ссылка this не исчезает во время построения, записи в final поля в конструкторе гарантированы для видимости на других потоках, даже если объект становится доступным для другого потока через гонку данных. (Записи на не-final поля не гарантируются, чтобы быть видимыми, поэтому, если вы неправильно их опубликовали, другой поток мог видеть их в частично сконструированном состоянии.)Scala и модель памяти Java

Есть ли какая-либо документация о том, как/если компилятор Scala создает final (а не не final) Поддерживаемые поля для классов? Я просмотрел спецификацию языка и искал в Интернете, но не могу найти окончательных ответов. (Для сравнения @scala.volatile аннотацию является документированы, чтобы отметить поле volatile)

ответ

4

Я вырыл через историю, чтобы узнать, когда было сделано изменение.

Проекция Scala в JVM не распространяется на спецификации языка.

+7

Но поведение, с точки зрения параллелизма, языковых конструкций должно быть частью его спецификации, я бы спорил! –

3

Это создает final поле, когда вы заявляете что-то как val. Все, ссылки на которые могут быть изменены, например var, могут (очевидно) не быть final внизу.

Это означает, что case classes содержат конечные поля также (в качестве аргументов в случае конструктор класса неявно val s)

+1

Я не думаю, что это было так (см., Например, http://old.nabble.com/Val-and-Final-td13355515.html). Часть причины моего вопроса - если это может измениться без какой-либо документации, как я узнаю, что это не изменится снова? –

+1

Вы правы, что это должно быть документировано. Это не просто проблема производительности, но и часть самого языка из-за модели памяти. Я не знал, что vals были неисчерпаемыми –

2

Я зарегистрировал ошибку в документации для этого в системе Scala bug.