KPL三個賽季S、A、B分組,es從未出S組,AG衰落,TTG一直穩定
包裝類
概念
- 基本資料型別所對應的引用資料型別
- Object可統一所有資料,包裝類的預設值是null
方法
1.型別轉換與裝箱、拆箱
裝箱和拆箱
概念
裝箱:棧--->堆(基本型別--->引用型別)。反之為拆箱
程式
JDK1.5前
1.5後自動裝箱拆箱
執行結果
反編譯理解自動裝箱拆箱
檢視反編譯後的程式碼,發現裝箱和拆箱操作IDEA自動幫我們完成了
2.基本型別和字串轉換
基本型別-->字串
1.加號法
2.Integer.toString()法
toString法可以通過radix來將要轉換的基本型別視為幾進位制
字串-->基本型別
Integer.parseXXX
Boolean-->基本型別
"true"-->true,非"true"-->false
完整程式
Integer緩衝區
概念
面試題
如上圖程式,同樣是自動裝箱,為何列印結果一個是true一個是false呢?
檢視反編譯後的程式碼
發現自動裝箱用的是Integer.valueof()
可以推斷,結果不同的原因就出在valueof上邊
檢視valueof原始碼
-
如果i在-128~127內,返回Integer緩衝區內的物件,原理如下圖所示
將Integer緩衝區100的地址賦給integer3和integer4,integer3==integer4當然是true -
如果i不在-128~127內,直接在堆內重新開闢空間
相當於給程式中的integer5和integer6分別重新開闢各自的堆空間並將地址賦給5 6
地址不同,5當然不等於6
3.String(存疑)
概述
不可變性
如上圖所示,首先在方法區的字串池開闢"hello"空間,棧內的name指向"hello"區
把"zhangsan"賦給name,並不是把"hello"區改為"zhangsan",而是重新開闢"zhangsan"區,name改變指向物件改為"zhangsan"區
此時"hello"如果沒人用,就變成垃圾了
將"zhangsan"同樣賦值給name2,就實現了字串常量共享,name和name2都指向"zhangsan"區,二者地址當然相同,如下圖
- 用new String()方式建立字串又不一樣了
如圖所示,此時"java"開闢了兩個空間
此時棧內被賦值的str指向的是堆內的"java"區(其實是直接指向方法區的)
其實jdk6以前的版本是存在方法區的,之後的版本字串常量池被移到堆中了
String常用方法
注意點都在以下的程式裡邊了
常用方法1
常用方法2
常用方法3
別忽略了空格
常用方法4
補充方法
- equals()比較是否相等,equalsIgnoreCase()是忽略大小寫的比較
- compareTo()比較大小,比較的一般是兩個字串在編碼表(位元組表)裡邊的位置
compareTo是逐個比較,相同就往下比,不同就不比後邊的了
上邊也說了,一般是比位置,如果是下圖這種情況肯定不是比位置了,比長度
String案例演示
3.插入easy
- replace:用easy text替換text
4.每個單詞首字母大寫
- 用split分開每個單詞
- 每個單詞首字母大寫
- 將首字母大寫後的每個單詞再拼回一句話:upperfirst + str1[i].substring(1);
程式實現
something+arr[].substring(下標):代表將下標以及之後位置的字元和something拼接起來
如上圖,將大寫後的字母與第0位及其之後位置的字元拼接了
可變字串
幾個常用方法
注意點都在以下程式註釋裡了
驗證StringBuilder比String速度快
String:
StringBuilder:
比較二者時間發現StringBuilder要比String快很多
BigDecimal的使用
為什麼會出現以上情況呢?
因為double儲存的是一個近似值,經過運算會出現很小的誤差,如何消除這種誤差呢?
藉助BigDecimal。注意:不能使用普通運算子
概述
注意點
- 計算順序問題,如下圖
- 除法除不盡的問題