1. 緩沖I/O
1.1. 對于檔案和套接字，壓縮和字串編碼的操作，必須適當地對I/O進行緩沖
1.1.1. 兩個流操作的是位元組塊（來自緩沖流）而不是一系列的單位元組（來自ObjectOutputStream），它們會運行得更好
1.2. InputStream.read()
1.3. OutputStream.write()
1.4. 操作的是單個字符
1.5. FileInputStream.read()
1.6. FileInputStream.write()
1.7. 慢
1.8. 二進制資料的檔案I/O
1.8.1. BufferedInputStream或BufferedOutputStream來包裝底層的檔案流
1.9. 使用字符（字串）資料的檔案I/O
1.9.1. BufferedReader或BufferedWriter來包裝底層的流
1.10. ByteArrayInputStream類和ByteArrayOutputStream類
1.10.1. 用緩沖過濾流包裝它們，意味著資料會被復制兩次
1.10.1.1. 被復制到過濾流的緩沖區
1.10.1.2. 被復制到ByteArrayInputStream的緩沖區
1.10.1.3. 輸出流也是如此
1.10.2. 在沒有其他流參與的時候，應該避免緩沖I/O
1.11. GZIPOutputStream
1.11.1. 操作資料塊比操作單位元組資料更高效
1.12. ObjectOutputStream
1.12.1. 將單位元組資料發送到下一個流
1.12.2. 下一個流是最終目的地
1.12.2.1. ByteArrayOutputStream，則無須緩沖
1.12.2.2. 中間有另一個過濾流，如GZIPOutputStream，有必要緩沖
2. 亂數
2.1. java.util.Random
2.1.1. 主要操作（nextGaussian()方法）是同步的
2.1.2. 鎖上都會產生競爭
2.2. java.util.concurrent.ThreadLocalRandom
2.2.1. 當每個執行緒都有自己的亂數生成器時，Random類的同步就不再是問題
2.3. 偽隨機演算法
2.3.1. 確定性的
2.3.1.1. 并不能真正做到隨機
2.3.2. 通過特定生成器查看這個數字序列，并最終算出下一個數字會是什么
2.4. java.security.SecureRandom
2.4.1. 使用一個系統介面來為其隨機資料獲取種子
2.4.2. 提供的資料基于真正的隨機事件（如滑鼠的移動）
2.4.3. 基于熵的隨機性（entropy-based randomness）
2.4.3.1. 更安全
2.4.4. generateSeed()方法花費的時間無法確定，這取決于系統有多少未使用的熵
2.4.4.1. 性能本身變成了隨機
2.4.4.2. 更好的解決方案是設定作業系統，使其提供更多的熵，這可以通過運行rngd守護行程來實作
2.4.5. SecureRandom類的阻塞問題可以通過修改配置來避免，但最好在作業系統層面通過給系統增加熵來解決
3. 類資料共享
3.1. Java 11
3.2. class data sharing，CDS
3.2.1. JVM之間共享類元資料的一種機制
3.2.2. 可以縮短JVM的啟動時間
3.3. 只適用于從模塊或JAR檔案加載的類，不能共享（或加速加載）來自檔案系統或網路URL的類
3.4. 常規的CDS（共享默認的JDK類）
3.5. 應用程式類資料共享
3.5.1. 可以共享任何一組類
3.6. XX:+DumpLoadedClassList=filename標志來運行你的應用程式
3.6.1. 將（在filename檔案中）生成一個串列，其中包含你的應用程式已經加載的所有類
3.7. 使用這個類串列來生成共享存檔
$ java -Xshare:dump -XX:SharedClassListFile=filename \
-XX:SharedArchiveFile=myclasses.jsa \
……類路徑引數……
3.8. 使用共享存檔來運行應用程式
$ java -Xshare:auto -XX:SharedArchiveFile=myclasses.jsa ……其他引數……
3.9. 要驗證類是否從共享存檔加載，可以在命令列加上類加載日志（-Xlog:class+load=info）命令
4. Java原生介面
4.1. （Java Native Interface，JNI）
4.2. 想要真正快速的代碼，應該使用原生代碼
4.3. 撰寫盡可能快的代碼感興趣，應該避免使用Java原生介面
4.4. 某個應用程式是用Java撰寫的，那么出于性能原因呼叫原生代碼幾乎總是一個壞主意
4.4.1. JNI并不能解決性能問題
4.4.2. Java代碼幾乎總是比呼叫原生代碼運行得更快
4.5. 盡可能避免從Java到C的呼叫
4.5.1. 從C呼叫回Java不會有很大的性能損失（取決于所涉及的引數）
4.5.2. 當使用JNI時，要限制從Java到C的呼叫次數，跨越JNI邊界的呼叫開銷很大
4.6. 引數不是基本型別，那么JNI代碼會表現得更差
4.7. 要讓固定陣列和字串的時間盡可能短
4.7.1. 垃圾回收器才不會受到影響
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/545117.html
標籤：其他
上一篇：并發專題一
下一篇：C語言程式設計