深刻解析Java編程中final症結字的感化。本站提示廣大學習愛好者：（深刻解析Java編程中final症結字的感化）文章只能為提供參考，不一定能成為您想要的結果。以下是深刻解析Java編程中final症結字的感化正文
final class
當一個類被界說成final class，表現該類的不克不及被其他類繼續，即不克不及用在extends以後。不然在編譯時代就會獲得毛病。
package com.iderzheng.finalkeyword;
public final class FinalClass {
}
// Error: cannot inherit from final
class PackageClass extends FinalClass {
}
Java支撐把class界說成final，仿佛違反了面向對象編程的根本准繩，但在另外一方面，關閉的類也包管了該類的一切辦法都是固定不變的，不會有子類的籠罩辦法須要去靜態加載。這給編譯器做優化時供給了更多的能夠，最好的例子是String，它就是final類，Java編譯器便可以把字符串常量（那些包括在雙引號中的內容）直接釀成String對象，同時對運算符+的操作直接優化成新的常量，由於final潤飾包管了不會有子類對拼接操作前往分歧的值。
關於一切分歧的類界說—頂層類(全局或包可見)、嵌套類(外部類或靜態嵌套類)都可以用final來潤飾。然則普通來講final多用來潤飾在被界說玉成局(public)的類上，由於關於非全局類，拜訪潤飾符曾經將他們限制了它們的也可見性，想要繼續這些類曾經很艱苦，就不消再加一層final限制。
別的要提到的是匿名類(Anonymous Class)固然說異樣不克不及被繼續，但它們並沒有被編譯器限制成final。
import java.lang.reflect.Modifier;
public class Main {
public static void main(String[] args) {
Runnable anonymous = new Runnable() {
@Override
public void run() {
}
};
System.out.println(Modifier.isFinal(anonymous.getClass().getModifiers()));
}
}
輸入：
false
final Method
跟繼續不雅念親密相干是多態(Polymorphism)，個中牽扯到了籠罩(Overriding)和隱蔽(Hiding)的概念差別（為便利起見，以下對這兩個概念同一稱為“重寫”）。但分歧於C++中辦法界說能否有加virtual症結字會影響子類雷同辦法簽名的辦法是籠罩照樣隱蔽，在Java裡子類用雷同辦法簽名重寫父類辦法，關於類辦法(靜態辦法)會構成隱蔽，而對象辦法(非靜態辦法)只產生籠罩。因為Java許可經由過程對象直接拜訪類辦法，也使得Java不許可在統一個類中類辦法和對象辦法有雷同的簽名。
final類限制了全部類不克不及被繼續，進而也表現該類裡的一切辦法都不克不及被子類所籠罩和隱蔽。當類不被final潤飾時，仍然可以對部門辦法應用final停止潤飾來避免這些辦法被子類重寫。
異樣的，如許的設計損壞了面向對象的多態性，然則final辦法可以包管其履行切實其實定性，從而確保了辦法挪用的穩固性。在一些框架設計中就會常常見到籠統類的一些已完成辦法的辦法被限制成final，由於在框架中一些驅動代碼會依附這些辦法的完成了完成既定的目的，所以不願望有子類對它停止籠罩。
下邊的例子展現了final潤飾在分歧類型的辦法中起到的感化：
package com.iderzheng.other;
public class FinalMethods {
public static void publicStaticMethod() {
}
public final void publicFinalMethod() {
}
public static final void publicStaticFinalMethod() {
}
protected final void protectedFinalMethod() {
}
protected static final void protectedStaticFinalMethod() {
}
final void finalMethod() {
}
static final void staticFinalMethod() {
}
private static final void privateStaticFinalMethod() {
}
private final void privateFinalMethod() {
}
}
package com.iderzheng.finalkeyword;
import com.iderzheng.other.FinalMethods;
public class Methods extends FinalMethods {
public static void publicStaticMethod() {
}
// Error: cannot override
public final void publicFinalMethod() {
}
// Error: cannot override
public static final void publicStaticFinalMethod() {
}
// Error: cannot override
protected final void protectedFinalMethod() {
}
// Error: cannot override
protected static final void protectedStaticFinalMethod() {
}
final void finalMethod() {
}
static final void staticFinalMethod() {
}
private static final void privateStaticFinalMethod() {
}
private final void privateFinalMethod() {
}
}
起首留意上邊的例子裡，FinalMethods和Methods是界說在分歧的包(package)下。關於第一個publicStaticMethod，子類勝利重寫了父類的靜態辦法，但由於是靜態辦法所以產生的實際上是“隱蔽”。詳細表示為挪用Methods.publicStaticMethod()會履行Methods類中的完成，挪用FinalMethods.publicStaticMethod()時履行其實不會產生多態加載子類的完成，而是直接應用FinalMethods的完成。所以在用子類去拜訪辦法時，會隱蔽了父類雷同辦法簽名的辦法的可見性。
關於全局辦法publicFinalMethod就像final潤飾辦法描寫的那樣制止子類界說雷同的辦法去籠罩它，在編譯時就會拋出異常。不外在子類界說辦法名字一樣然則帶有個參數，好比：publicFinalMethod(String x)是可以的，由於這是同步的辦法簽名。
在Intellij裡，IDE對publicStaticFinalMethod顯示了一個正告：'static' method declared 'final'。在它看來這是過剩的，但從實例中可以看出final異樣制止了子類界說雷同的靜態辦法去隱蔽它。在現實開辟中，子類和父類界說雷同的靜態辦法的行動是極其不推舉的，由於隱蔽辦法須要開辟者留意應用分歧類名限制會有分歧的後果，就很輕易帶來毛病。並且在類的外部是可以不應用類名限制直接挪用靜態辦法，開辟者再度做繼續時能夠沒有留意到隱蔽的存在默許在應用父類的辦法時就會發明不是預期的成果。所以對靜態辦法應當默許曾經是final而不應去隱蔽他們，也是以IDE認為是過剩的潤飾。
父類中protected潤飾和public潤飾的辦法關於子類都是可見的，所以final潤飾protected辦法的情形和public辦法是一樣的。想提到的是在現實開辟中普通很少界說protected靜態辦法，由於如許的辦法適用性太低。
關於父類package辦法，處在分歧的package下的子類是弗成見的，private辦法曾經定制了只要父類本身可拜訪。所以編譯器許可子類去界說雷同的辦法。但這不構成籠罩或隱蔽，由於父類曾經經由過程潤飾符來隱蔽了這些辦法，而非子類的重寫形成的。固然假如子類和父類在統一package下，那末情形也和之前的public、protected一樣了。
final辦法為什麼會高效：
final辦法會在編譯的進程中應用內嵌機制停止inline優化。inline優化是指：在編譯的時刻直接挪用函數代碼調換，而不是在運轉時挪用函數。inline須要在編譯的時刻就曉得最初要用哪一個函數， 明顯，非final是不可的。非final辦法能夠在子類中被重寫，因為能夠湧現多態的情形，編譯器在編譯階段其實不能肯定未來挪用辦法的對象的真正類型，也就沒法肯定究竟挪用哪一個辦法。
final Variable
簡略說，Java裡的final變量只能且必需被初始化一次，以後該變量就與該值綁定。但該次賦值紛歧定要在變量被界說時被連忙初始化，Java也支撐經由過程前提語句給final變量分歧的成果，只是不管若何該變量都只能變賦值一次。
不外Java的final變量並不是相對的常量，由於Java的對象變量只是援用值，所以final只是表現該援用不克不及轉變，而對象的內容仍然可以修正。比較C/C++的指針，它更像是type * const variable而非type const * variable。
Java的變量可以分為兩類：部分變量(Local Variable)和類成員變量(Class Field)。下邊照樣用代碼來分離引見它們的初始化情形。
Local Variable
部分變量重要指界說在辦法中的變量，出了辦法它們就會消逝弗成拜訪。個中有可分出一種特別情形：函數參數。關於這類情形，其初始化與函數被挪用時傳入的參數綁定。
關於其他的部分變量，它們被界說在辦法中，其值便可以被有前提的初始化：
public String method(final boolean finalParam) {
// Error: final parameter finalParam may not be assigned
// finalParam = true;
final Object finalLocal = finalParam ? new Object() : null;
final int finalVar;
if (finalLocal != null) {
finalVar = 21;
} else {
finalVar = 7;
}
// Error: variable finalVar might already have been assigned
// finalVar = 80;
final String finalRet;
switch (finalVar) {
case 21:
finalRet = "me";
break;
case 7:
finalRet = "she";
break;
default:
finalRet = null;
}
return finalRet;
}
從上述例子中可以看出被final潤飾的函數參數沒法被付與新的值，然則其他final的部分變量則可以在前提語句中被賦值。如許也給final供給了必定的靈巧性。
固然前提語句中的一切前提裡都應當包括對final部分變量的賦值，不然就會獲得變量能夠未被初始化的毛病
public String method(final Object finalParam) {
final int finalVar;
if (finalParam != null) {
finalVar = 21;
}
final String finalRet;
// Error: variable finalVar might not have been initialized
switch (finalVar) {
case 21:
finalRet = "me";
break;
case 7:
finalRet = "she";
break;
}
// Error: variable finalRet might not have been initialized
return finalRet;
}
實際上部分變量沒有被界說成final的需要，公道設計的辦法應當可以很好的保護部分變量。只是在Java辦法中應用匿名函數做閉包時，Java請求被援用的部分變量必需被界說為final：
public Runnable method(String string) {
int integer = 12;
return new Runnable() {
@Override
public void run() {
// ERROR: needs to be declared final
System.out.println(string);
// ERROR: needs to be declared final
System.out.println(integer);
}
};
}
Class Field
類成員變量其實也能分紅兩種：靜態和非靜態。關於靜態類成員變量，由於它們與類相干，所以除在界說時直接初始化，還可以放在static block中，而應用後者可以履行更多龐雜的語句：
package com.iderzheng.finalkeyword;
import java.util.HashSet;
import java.util.LinkedHashSet;
import java.util.Set;
public class StaticFinalFields {
static final int STATIC_FINAL_INIT_INLINE = 7;
static final Set<Integer> STATIC_FINAL_INIT_STATIC_BLOCK;
/** Static Block **/
static {
if (System.currentTimeMillis() % 2 == 0) {
STATIC_FINAL_INIT_STATIC_BLOCK = new HashSet<>();
} else {
STATIC_FINAL_INIT_STATIC_BLOCK = new LinkedHashSet<>();
}
STATIC_FINAL_INIT_STATIC_BLOCK.add(7);
STATIC_FINAL_INIT_STATIC_BLOCK.add(21);
}
}
Java中也有非靜態的block可以對非靜態的成員變量停止初始化，然則關於這些變量，更多的時刻照樣放在結構函數(constructor)裡停止初始化。固然必需包管每一個final變量在結構函數裡都有被初始化一次，假如經由過程this()挪用了其他的結構函數，則這些final變量不克不及再在該結構函數裡被賦值了。
package com.iderzheng.finalkeyword;
public class FinalFields {
final long FINAL_INIT_INLINE = System.currentTimeMillis();
final long FINAL_INIT_BLOCK;
final long FINAL_INIT_CONSTRUCTOR;
/** Initial Block **/
{
FINAL_INIT_BLOCK = System.nanoTime();
}
FinalFields() {
this(217);
}
FinalFields(boolean bool) {
FINAL_INIT_CONSTRUCTOR = 721;
}
FinalFields(long init) {
FINAL_INIT_CONSTRUCTOR = init;
}
}
當final用來潤飾類(Class) 和辦法(Method)時，它重要影響面向對象的繼續性，沒有了繼續性就沒有了子類對父類的代碼依附，所以在保護時修正代碼就不消斟酌會不會損壞子類的完成，就顯得加倍便利。而當它用在變量(Variable)上時，Java包管了變量值不會修正，更進一步設計包管類的成員也不克不及修正的話，那末全部變量便可以釀成常量應用，關於多線程編程長短常有益的。所以final關於代碼保護有異常好的感化。
