Улучшает ли использование ключевое слово final в Java?

В Java мы видим много мест, где finalключевое слово можно использовать, но его использование встречается редко.

Например:

String str = "abc";
System.out.println(str);

В приведенном выше случае, strможет быть, finalно это обычно прекращается.

Когда метод никогда не будет переопределен, мы можем использовать ключевое слово final. Точно так же в случае класса, который не будет наследоваться.

Действительно ли использование ключевого слова final в любом из этих случаев действительно повышает производительность? Если так, то как? Пожалуйста, объясни. Если правильное использование finalдействительно имеет значение для производительности, какие привычки должен разработать Java-программист, чтобы наилучшим образом использовать ключевое слово?

Обычно нет. Для виртуальных методов, HotSpot отслеживает , есть ли способ на самом деле переопределен, и может выполнять оптимизации, такие как встраивание, в предположении, что метод не был переопределен - до тех пор, пока он не загрузит класс, который переопределяет метод, и в этот момент он может отменить (или частично отменить) эти оптимизации.

(Конечно, это предполагает, что вы используете HotSpot - но это, безусловно, самая распространенная JVM, так что ...)

На мой взгляд, вы должны использовать final на основе четкого дизайна и удобочитаемости, а не по соображениям производительности. Если вы хотите что-то изменить по соображениям производительности, вам следует выполнить соответствующие измерения, прежде чем изгибать наиболее четкий код из формы - таким образом, вы можете решить, стоит ли какая-либо дополнительная достигнутая производительность в худшей читаемости / дизайне. (По моему опыту это почти никогда не стоит; YMMV.)

РЕДАКТИРОВАТЬ: Поскольку последние поля были упомянуты, стоит упомянуть, что они в любом случае являются хорошей идеей с точки зрения четкого дизайна. Они также изменяют гарантированное поведение с точки зрения видимости между потоками: после завершения конструктора все конечные поля гарантированно сразу же становятся видимыми в других потоках. Это, пожалуй, наиболее распространенное использование finalв моем опыте, хотя, как сторонник эмпирического правила Джоша Блоха "я должен использовать его finalчаще для занятий ..."

Короткий ответ: не беспокойся об этом!

Длинный ответ:

Когда говорим об окончательных локальных переменных имейте в виду, что использование ключевого слова finalпоможет компилятору статически оптимизировать код , что в конечном итоге может привести к более быстрому коду. Например, последние строки a + bв примере ниже сцепляются статически (во время компиляции).

public class FinalTest {

    public static final int N_ITERATIONS = 1000000;

    public static String testFinal() {
        final String a = "a";
        final String b = "b";
        return a + b;
    }

    public static String testNonFinal() {
        String a = "a";
        String b = "b";
        return a + b;
    }

    public static void main(String[] args) {
        long tStart, tElapsed;

        tStart = System.currentTimeMillis();
        for (int i = 0; i < N_ITERATIONS; i++)
            testFinal();
        tElapsed = System.currentTimeMillis() - tStart;
        System.out.println("Method with finals took " + tElapsed + " ms");

        tStart = System.currentTimeMillis();
        for (int i = 0; i < N_ITERATIONS; i++)
            testNonFinal();
        tElapsed = System.currentTimeMillis() - tStart;
        System.out.println("Method without finals took " + tElapsed + " ms");

    }

}

Результат?

Method with finals took 5 ms
Method without finals took 273 ms

Протестировано на Java Hotspot VM 1.7.0_45-b18.

Так сколько же фактическое улучшение производительности? Я не смею говорить. В большинстве случаев, вероятно, маргинальный (~ 270 наносекунд в этом синтетическом тесте, потому что объединение строк вообще исключается - редкий случай), но в сильно оптимизированном коде утилит это может быть фактором. В любом случае ответ на первоначальный вопрос - да, это может улучшить производительность, но в лучшем случае незначительно .

Помимо преимуществ времени компиляции, я не смог найти никаких доказательств того, что использование ключевого слова finalоказывает какое-либо измеримое влияние на производительность.

Да, оно может. Вот пример, где final может повысить производительность:

Условная компиляция - это метод, при котором строки кода не компилируются в файл класса на основании определенного условия. Это можно использовать для удаления тонны кода отладки в производственной сборке.

учтите следующее:

public class ConditionalCompile {

  private final static boolean doSomething= false;

    if (doSomething) {
       // do first part. 
    }

    if (doSomething) {
     // do second part. 
    }

    if (doSomething) {     
      // do third part. 
    }

    if (doSomething) {
    // do finalization part. 
    }
}

Преобразовав атрибут doSomething в последний атрибут, вы сказали компилятору, что всякий раз, когда он видит doSomething, он должен заменить его на false в соответствии с правилами подстановки во время компиляции. Первый проход компилятора изменяет код на что-то вроде этого:

public class ConditionalCompile {

  private final static boolean doSomething= false;

    if (false){
       // do first part. 
    }

    if (false){
     // do second part. 
    }

    if (false){
      // do third part. 
    }

    if (false){
    // do finalization part. 

    }
}

Как только это будет сделано, компилятор еще раз посмотрит на него и обнаружит, что в коде есть недостижимые операторы. Поскольку вы работаете с высококачественным компилятором, ему не нравятся все эти недоступные байтовые коды. Таким образом это удаляет их, и вы в конечном итоге с этим:

public class ConditionalCompile {


  private final static boolean doSomething= false;

  public static void someMethodBetter( ) {

    // do first part. 

    // do second part. 

    // do third part. 

    // do finalization part. 

  }
}

таким образом уменьшая любые избыточные коды или любую ненужную условную проверку.

Изменить: В качестве примера, давайте возьмем следующий код:

public class Test {
    public static final void main(String[] args) {
        boolean x = false;
        if (x) {
            System.out.println("x");
        }
        final boolean y = false;
        if (y) {
            System.out.println("y");
        }
        if (false) {
            System.out.println("z");
        }
    }
}

При компиляции этого кода с Java 8 и декомпиляции с помощью javap -c Test.classмы получаем:

public class Test {
  public Test();
    Code:
       0: aload_0
       1: invokespecial #8                  // Method java/lang/Object."<init>":()V
       4: return

  public static final void main(java.lang.String[]);
    Code:
       0: iconst_0
       1: istore_1
       2: iload_1
       3: ifeq          14
       6: getstatic     #16                 // Field java/lang/System.out:Ljava/io/PrintStream;
       9: ldc           #22                 // String x
      11: invokevirtual #24                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      14: iconst_0
      15: istore_2
      16: return
}

Мы можем заметить, что скомпилированный код включает только не финальную переменную x. Это доказывает, что конечные переменные влияют на производительность, по крайней мере, для этого простого случая.

Согласно IBM - это не для классов или методов.

http://www.ibm.com/developerworks/java/library/j-jtp04223.html

Я поражен тем, что на самом деле никто не опубликовал какой-то реальный код, который был декомпилирован, чтобы доказать, что есть хоть какая-то незначительная разница.

Для справки это было проверено на соответствие javacверсии 8, 9и10 .

Предположим, этот метод:

public static int test() {
    /* final */ Object left = new Object();
    Object right = new Object();

    return left.hashCode() + right.hashCode();
}

Компиляция этого кода , как она есть, производит точно такой же байт - код , как когда finalбы присутствовал (final Object left = new Object(); ).

Но этот:

public static int test() {
    /* final */ int left = 11;
    int right = 12;
    return left + right;
}

Производит:

   0: bipush        11
   2: istore_0
   3: bipush        12
   5: istore_1
   6: iload_0
   7: iload_1
   8: iadd
   9: ireturn

Уход, finalчтобы присутствовать, производит:

   0: bipush        12
   2: istore_1
   3: bipush        11
   5: iload_1
   6: iadd
   7: ireturn

Код в значительной степени не требует пояснений, в случае, если есть постоянная времени компиляции, он будет загружен непосредственно в стек операндов (он не будет сохранен в массив локальных переменных, как в предыдущем примере через bipush 12; istore_0; iload_0 ), что имеет смысл так как никто не может изменить это.

С другой стороны, почему во втором случае компилятор не выдает, istore_0 ... iload_0это за мной, это не похоже на этот слот0 используется каким-либо образом (он может уменьшить массив переменных таким образом, но может быть, я пропускаю некоторые внутренние детали, не могу расскажу наверняка)

Я был удивлен, увидев такую ​​оптимизацию, учитывая, как это javacделают маленькие . Что мы должны всегда использовать final? Я даже не собираюсь писать JMHтест (который я хотел изначально), я уверен, что различия в порядке ns(если это вообще возможно). Единственное место, где это может быть проблемой, - это когда метод не может быть встроен из-за его размера (и объявленияfinal уменьшит этот размер на несколько байтов).

Есть еще два finalвопроса, которые необходимо решить. Во-первых, когда метод final(с JITточки зрения), такой метод является мономорфным - и это самые любимые изJVM .

Тогда есть finalпеременные экземпляра (которые должны быть установлены в каждом конструкторе); они важны, так как они гарантируют правильно опубликованную ссылку, о которой мы немного поговорили, а также указано именно JLS.

Вы действительно спрашиваете о двух (как минимум) разных случаях:

1. final для локальных переменных
2. final для методов / классов

Джон Скит уже ответил 2). О 1):

Я не думаю, что это имеет значение; для локальных переменных компилятор может определить, является ли переменная конечной или нет (просто проверяя, назначена ли она более одного раза). Поэтому, если компилятор хочет оптимизировать переменные, которые назначаются только один раз, он может это сделать независимо от того, объявлена ​​ли переменная на самом деле finalили нет.

final мощь иметь значение для полей защищенного / публичного класса; там компилятору очень трудно узнать, задано ли поле более одного раза, как это может происходить из другого класса (который, возможно, даже не был загружен). Но даже тогда JVM могла бы использовать технику, описанную Джоном (оптимистично оптимизировать, вернуться, если загружен класс, который меняет поле).

Таким образом, я не вижу никаких причин, почему это должно помочь производительности. Так что этот вид микрооптимизации вряд ли поможет. Вы можете попробовать сравнить его, чтобы убедиться, но я сомневаюсь, что это будет иметь значение.

Редактировать:

На самом деле, согласно ответу Тимо Весткемпера, в некоторых случаях final можно повысить производительность полей классов. Я исправлен.

Примечание: не эксперт по Java

Если я правильно запомнил java, было бы очень мало способов улучшить производительность, используя ключевое слово final. Я всегда знал, что он существует для «хорошего кода» - дизайна и читабельности.

Я не эксперт, но я полагаю, вам следует добавить finalключевое слово в класс или метод, если оно не будет перезаписано, и оставить переменные в покое. Если будет какой-либо способ оптимизировать такие вещи, компилятор сделает это за вас.

На самом деле, во время тестирования некоторого кода, связанного с OpenGL, я обнаружил, что использование модификатора final в приватном поле может снизить производительность. Вот начало класса, который я тестировал:

public class ShaderInput {

    private /* final */ float[] input;
    private /* final */ int[] strides;


    public ShaderInput()
    {
        this.input = new float[10];
        this.strides = new int[] { 0, 4, 8 };
    }


    public ShaderInput x(int stride, float val)
    {
        input[strides[stride] + 0] = val;
        return this;
    }

    // more stuff ...

И этот метод я использовал для тестирования производительности различных альтернатив, среди которых класс ShaderInput:

public static void test4()
{
    int arraySize = 10;
    float[] fb = new float[arraySize];
    for (int i = 0; i < arraySize; i++) {
        fb[i] = random.nextFloat();
    }
    int times = 1000000000;
    for (int i = 0; i < 10; ++i) {
        floatVectorTest(times, fb);
        arrayCopyTest(times, fb);
        shaderInputTest(times, fb);
        directFloatArrayTest(times, fb);
        System.out.println();
        System.gc();
    }
}

После третьей итерации с разогретой виртуальной машиной я постоянно получал эти цифры без последнего ключевого слова:

Simple array copy took   : 02.64
System.arrayCopy took    : 03.20
ShaderInput took         : 00.77
Unsafe float array took  : 05.47

С последним ключевым словом:

Simple array copy took   : 02.66
System.arrayCopy took    : 03.20
ShaderInput took         : 02.59
Unsafe float array took  : 06.24

Обратите внимание на цифры для теста ShaderInput.

Не имело значения, сделал ли я поля открытыми или закрытыми.

Кстати, есть еще несколько сбивающих с толку вещей. Класс ShaderInput превосходит все другие варианты, даже с ключевым словом final. Это замечательно, потому что это класс, обертывающий массив с плавающей точкой, в то время как другие тесты напрямую манипулируют массивом. Надо понять это. Может иметь отношение к свободному интерфейсу ShaderInput.

Также System.arrayCopy, по-видимому, на самом деле несколько медленнее для небольших массивов, чем простое копирование элементов из одного массива в другой в цикле for. И использование sun.misc.Unsafe (а также прямой java.nio.FloatBuffer, не показанный здесь) работает ужасно.

Final (по крайней мере, для переменных и параметров членов) больше для людей, чем для машины.

Хорошей практикой является сделать переменные окончательными, где это возможно. Я бы хотел, чтобы Java по умолчанию делала final с переменными и имела ключевое слово Mutable, чтобы разрешить изменения. Неизменяемые классы приводят к гораздо лучшему многопоточному коду, и просто взгляд на класс с «final» перед каждым членом быстро покажет его неизменность.

Другой случай - я конвертировал много кода для использования аннотаций @ NonNull / @ Nullable (Вы можете сказать, что параметр метода не должен быть нулевым, тогда IDE может предупреждать вас всякий раз, когда вы передаете переменную, которая не помечена @ NonNull - все это распространяется до нелепой степени). Гораздо проще доказать, что переменная-член или параметр не могут иметь значение null, если они помечены как final, поскольку вы знаете, что они не будут переназначаться где-либо еще.

Мое предложение состоит в том, чтобы привыкнуть применять final для элементов и параметров по умолчанию. Это всего лишь несколько символов, но это подтолкнет вас к улучшению стиля кодирования, если ничего больше.

Final для методов или классов - это еще одна концепция, поскольку она запрещает очень правильную форму повторного использования и на самом деле мало что говорит читателю. Лучшее использование, вероятно, - это то, как они сделали String и другие встроенные типы окончательными, чтобы вы могли повсеместно полагаться на согласованное поведение - это предотвратило много ошибок (хотя бывали случаи, когда я ЛЮБИЛ, чтобы расширять строку .... о возможности)

Как упоминалось в другом месте, 'final' для локальной переменной и, в несколько меньшей степени, переменной-члена, больше зависит от стиля.

'final' - это утверждение, что вы намерены изменить переменную (т. е. переменная не будет меняться!). Затем компилятор может помочь вам, подав жалобу, если вы нарушаете собственное ограничение.

Я разделяю мнение, что Java был бы лучшим языком, если бы идентификаторы (извините, я просто не могу назвать неизменную вещь «переменная») были окончательными по умолчанию и требовали от вас явного указания, что они являются переменными. Но, сказав это, я обычно не использую 'final' для локальных переменных, которые инициализируются и никогда не назначаются; это просто кажется слишком шумным.

(Я использую final для переменных-членов)

Члены, объявленные с помощью final, будут доступны по всей программе, потому что, в отличие от нефинальных, если эти члены не использовались в программе, сборщик мусора не позаботится о них, что может вызвать проблемы с производительностью из-за плохого управления памятью.

final Ключевое слово может быть использовано в Java пятью способами.

1. Урок окончательный
2. Ссылочная переменная является окончательной
3. Локальная переменная является окончательной
4. Метод является окончательным

Класс final: класс final означает, что мы не можем расширяться или наследование означает, что наследование невозможно.

Точно так же - объект является конечным: некоторое время мы не изменяли внутреннее состояние объекта, поэтому в таком случае мы можем указать, что объект является конечным объектом. Объект final означает, что переменная также не окончательная.

Как только ссылочная переменная становится окончательной, она не может быть переназначена другому объекту. Но может изменить содержимое объекта, пока его поля не являются окончательными