Одна ситуация вынудила запилить вопросец.
На первый взгляд ничего по этому поводу в голову не приходит, но если начать читать про синглтоны первые попавшиеся статейки, то вот что получается:

http://www.journaldev.com/1377/java-singleton-design-pattern-best-practices-examples#static-block-initialization

тут у них final




а тут как бы нет




И всплывает что-то в памяти, что где-то читал, что static инициализируется при загрузке класса(что тоже вызывает сомнения, ибо я всё таки считаю, что не при инициализации а при обращении) и это даёт типа какие-то гарантии.

Поясните плиз.

и тут ещё пишут:



http://www.journaldev.com/171/thread-safety-in-java-singleton-classes-with-example-code There are three ways through which we can achieve thread safety.

Create the instance variable at the time of class loading.

Pros:
Thread safety without synchronization
Easy to implement

Cons:
Early creation of resource that might not be used in the application.
The client application can’t pass any argument, so we can’t reuse it. For example, having a generic singleton class for database connection where client application supplies database server properties.

Blazkowiczquestionerя всё таки считаю, что не при инициализации а при обращении
Я тебе уже давал ссылку на JLS. Там академически точно описан порядок загрузки и инициализации класса. А ты выдумаваешь что-то своё.

что не при инициализации загрузке а при обращении

Blazkowicz https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4
и ищем всё про static.

Это ж пипец не для человеков чтиво. Я вот не увидел никаких гарантий

Alexey TominquestionerИ всплывает что-то в памяти, что где-то читал, что static инициализируется при загрузке класса(что тоже вызывает сомнения, ибо я всё таки считаю, что не при инициализации а при обращении) и это даёт типа какие-то гарантии.

Поясните плиз.

Гарантии даёт только страховой полис final . Статик или нет- уже не столь важно.
Если static final то любой кто обратился к классу получет корректный (если других ошибок нет) объект в поле. Всё.
Только надо понимать, что это обеспечивается через синхронизацию на глобальном объекте (именно static ), поэтому при создании таких объектов не надо делать что-то долго, а то можно всю JVM раком поставить

Да, я тоже так думаю, только непонятно почему в интернете куча информации, противоречащая этой

Blazkowiczquestionerкуча информации, противоречащая этой
Например?

например

https://habrahabr.ru/post/27108/

читать от авторИ вы будете правы, так как проблему многопоточности мы решили

Blazkowiczquestionerчитать от
Как это можно вообще читать???
OMFG1. Ленивую инициализацию (Объект instance будет создан classloader-ом во время инициализации класса)
2. Отсутствует возможность обработки исключительных ситуаций(exceptions) во время вызова конструктора
1. А то что загрузка и инициализация классов в Java ленивая для автора открытие?
2. Это вообще за гранью. 100500 вариантов обработать исключение хоть в конструкторе, хоть в блоке статической инициализации, но у автора "отсутствует возможность".

1 - по ходу да

2 - он имеет ввиду конкретно в этой имплементации

забыл ник,

с тех пор static изменил поведение? или раньше одни идиоты жили?

Blazkowicz,

http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4.2

ну да, тут же смотрю

http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4.2 For each class or interface C, there is a unique initialization lock LC . The mapping from C to LC is left to the discretion of the Java Virtual Machine implementation. The procedure for initializing C is then as follows:

Synchronize on the initialization lock, LC, for C. This involves waiting until the current thread can acquire LC.

If the Class object for C indicates that initialization is in progress for C by some other thread, then release LC and block the current thread until informed that the in-progress initialization has completed, at which time repeat this step.

If the Class object for C indicates that initialization is in progress for C by the current thread, then this must be a recursive request for initialization. Release LC and complete normally.

If the Class object for C indicates that C has already been initialized, then no further action is required. Release LC and complete normally.

If the Class object for C is in an erroneous state, then initialization is not possible. Release LC and throw a NoClassDefFoundError.

...

мелкий шрифт

An implementation may optimize this procedure by eliding the lock acquisition in step 1 (and release in step 4/5) when it can determine that the initialization of the class has already completed, provided that, in terms of the memory model, all happens-before orderings that would exist if the lock were acquired, still exist when the optimization is performed.

Так что получается безопасно и без final что ли?

Молчание - признак согласия.

В общем я тогда буду уверен, что если static инициализируется в блоке инициализации или inline, то видимость и так гарантирована и final писать не обязательно.