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.垃圾回收器才不会受到影响
