Для методов - вряд ли. Если брать прсто компилятор, то final методы он компилирует точно в такую же инструкцию invokevirtual, что и обычные методы. Это сделано для обратной совместимости с клиентским кодом, используюшим методоы, которые вдруг были перекомпилированы с удалением или добавлением final. Здесь в конце статьи описано подробнее: https://blogs.oracle.com/javamagazine/post/mastering-the-mechanics-of-java-method-invocation Что касается JIT компилятора, то у него есть механизмы оптимизации байткода и он все равно производит глобальный анализ дерева классов при загрузке. Хотя, возможно, final и является директивой для JIT в каких-то реализациях JVM, но и то только только на этапе анализа класса при загрузке. Но в любом случае к vtable это отношения не имеет. Так что касательно методов и классов final несет больше семантический смысл, чем прирост производительности.
Зато final полезно при объявлении статических полей класса. Т.к. в этом случае значения, указанные в static final поля при компиляции напрямую инлайнятся в стек операндов тех методов, которые его используют (например вызывается инструкция iconst_0 для интового поля), без предварительной инициализации класса. В противном случае, обращение к static полю без final компилируется в инструкцию getstatic, которая уже производит инициализацию класса перед обращением к полю, что, соответственно, занимает время и память.
Статья очередного желторотика, у которого наступила стадия отрицания при осознании того, что программирование - это, оказывается, не про HelloWorld и не про a + b
По сути Virtual Threads это и есть тот же реактивный стек, только спрятанный под капотом JVM. Вопрос еще - сколько там таится косяков (начиная от багов с потоками и заканчивая возможными уязвимостями) и сколько понадобится времени на их устранение.
Для методов - вряд ли. Если брать прсто компилятор, то final методы он компилирует точно в такую же инструкцию
invokevirtual, что и обычные методы. Это сделано для обратной совместимости с клиентским кодом, используюшим методоы, которые вдруг были перекомпилированы с удалением или добавлением final. Здесь в конце статьи описано подробнее: https://blogs.oracle.com/javamagazine/post/mastering-the-mechanics-of-java-method-invocationЧто касается JIT компилятора, то у него есть механизмы оптимизации байткода и он все равно производит глобальный анализ дерева классов при загрузке. Хотя, возможно, final и является директивой для JIT в каких-то реализациях JVM, но и то только только на этапе анализа класса при загрузке. Но в любом случае к vtable это отношения не имеет.
Так что касательно методов и классов
finalнесет больше семантический смысл, чем прирост производительности.Зато
finalполезно при объявлении статических полей класса. Т.к. в этом случае значения, указанные вstatic finalполя при компиляции напрямую инлайнятся в стек операндов тех методов, которые его используют (например вызывается инструкцияiconst_0для интового поля), без предварительной инициализации класса. В противном случае, обращение кstaticполю безfinalкомпилируется в инструкциюgetstatic, которая уже производит инициализацию класса перед обращением к полю, что, соответственно, занимает время и память.Статья очередного желторотика, у которого наступила стадия отрицания при осознании того, что программирование - это, оказывается, не про HelloWorld и не про a + b
Есть один замечательный канал по электронике для начинающих:
https://www.youtube.com/@HiDev
Там товарищ очень доходчиво объясняет принципы работы электронных компонентов и устройств.
Вот, в частности, видос про полупроводники:
https://www.youtube.com/watch?v=OMGdSCaMVD0&list=PL1s3wneoR_-on-07THWG5GFEZ-_mm-Pd2
По сути Virtual Threads это и есть тот же реактивный стек, только спрятанный под капотом JVM. Вопрос еще - сколько там таится косяков (начиная от багов с потоками и заканчивая возможными уязвимостями) и сколько понадобится времени на их устранение.