咱們先來看一段很簡單的JAVA代碼
這段代碼非常簡單，沒有任何技術含量。但是，如果我們把這段代碼改成下面的樣子
大家可以看到，我們只是用一個變量a代替了原來賦值表達式當中的常量1，就會出現(xiàn)語法錯誤，這是為什么呢？今天我們就用一篇短文來聊聊這個話題。
我們知道，Java語言中有4種整數(shù)類型，分別是byte、short、int和long。其中，Java編譯器對byte和short類型的變量在賦值的時候，做了一點點“特殊檢查”。那么編譯器如何“特殊檢查”這兩種類型的變量呢？當編譯器看到為這兩種類型的變量進行賦值的時候，要進行“超范圍檢查”，也就是說，會檢查一下給變量所賦的值會不會有可能超過范圍。如果編譯器認為所賦的值有可能超過這個變量所能存儲的最大值或最小值，那么就會報語法錯誤。但是很多人都會問，程序中給變量s所賦的值并沒有超過范圍，為什么會報錯呢？
這就要說說編譯器的檢查機制。當編譯器看到程序中并不是用一個簡單的數(shù)值對變量s進行賦值，而是把一個算術表達式賦值給了s，并且算術表達式中還出現(xiàn)了變量。這時候編譯器就會認為這次賦值操作有可能會把一個超范圍的值賦值給s，所以就報錯。
可能有讀者會問：第1段代碼當中，也是用算術表達式給變量s賦值，為什么會就沒有出現(xiàn)語法錯呢？問題就在于：第2段程序中，給變量s賦值的算術表達式里出現(xiàn)了變量。編譯器認為，既然是“變量”，就有可能發(fā)生改變，是一種不確定因素。編譯器并不去管變量當前的值到底是多少，它認為只要是變量參與了運算，變量值有可能變化，從而可能導致賦值超范圍，因此報出了語法錯誤。
如果我們把第2段程序中的變量a前面加上一個final關鍵字會如何呢？請看下面的代碼
當a前面加上了final關鍵字，a的值不能再發(fā)生變化，它變成了一個常量。編譯器就會認定這次賦值是安全的，因為a的值永遠都是1，賦值肯定不會超過范圍。
那么，是不是給s賦值的算術表的時候中不出現(xiàn)變量，賦值操作就一定不會報錯呢？其實并不是這樣，請看下面的例子
這次賦值操作，“=”右邊的算術表達式中并沒有出現(xiàn)變量，但是仍然會報語法錯誤，原因就是，編譯器會提前把算術表達式的值算出來，如果發(fā)現(xiàn)算出來的值已經超過了byte或short的數(shù)據(jù)范圍，也會報錯。因此第4段程序也不能通過編譯。
到這里，大家可以記住兩個結論：
- 給byte或short變量進行賦值時，“=”右邊如果是一個算術表達式，并且表達式中出現(xiàn)變量，肯定無法通過編譯。
- 即使用常量給byte或short變量進行賦值，如果在“編譯階段”就能確定所賦的值已經超過了范圍，同樣會報錯。
另外還要提醒大家，對int和long類型的變量進行賦值的時候，編譯器并不采用這樣的特殊檢查措施。請看以下代碼
大家可以看到，在上面的程序中，我們給int類型變量i1賦值時，“=”右邊也是一個算術表達式，并且表達式中也有變量，但不會出現(xiàn)語法錯誤。而給i2進行賦值時，“=”右邊的值已經超過了int類型的范圍，也不會有問題。
通過這篇短文，相信小伙伴一定能弄明白為什么給byte和short變量賦值的時候會出錯的原因。
