Java SE API know how
Java原生接口 （Java Native Interface）
访问特殊的，操作系统特有的函数或者C/C++函数库就需要JNI
跨越JNI边界的成本很高，调用现有C库首先要编写胶水代码（健壮性难以保证）
如果涉及的参数类型不是基本类型的开销：
- 简单的引用也需要进行地址转换
- 对基于数组的数据，操作需要在原生代码中进行特殊处理。
- String对象本质上也是一个数组，访问数组中的元素必须执行特殊的调用，让对象固定在内存中，当不需要数组的时候必须显式释放
异常
根据良好的程序设计准则使用异常，主要是应该仅在发生意料之外的事情时抛出异常
影响异常处理的一般性能：
- 创建一个try-catch块成本很高
jvm层面当异常块中的代码调用jvm会为该方法创建一个栈帧，将栈帧压入当前线程的虚拟机栈，在栈帧中，jvm会为try-catch分配一个异常表，记录try块中抛出的异常和对应的catch块的处理逻辑。当try块发生异常，jvm会根据异常类型在异常表中找到能够处理该异常的catch块，并将该程序跳转到catch块逻辑。如果没有在异常表找到处理逻辑的catch块，异常会向上抛出，上一级处理。 - 在异常点获取栈运行轨迹——当栈运行轨迹很长可想而知开销更大
100%命中异常的处理时间
- 受查的异常，浅层和深层的差异根本原因是栈轨迹的构造时间，这取决于栈的深度
- 非受查异常，JVM会在访问空指针的时候创建异常
在某一时刻发生的事情编译器会优化系统生成异常。jvm会重用同一个对象而不是每次都是新的对象生成。
每次执行相关代码，无论调用栈是什么样，该对象都会重用，减少构建站轨迹的时间，只有在完整栈信息的异常抛出相当长时间才会出现这种优化的现象 - 没有异常抛出的情况
防御性编程做了相当多的工作来创建对象，对照其他例子的区别在于创建，抛出和捕获异常的实际时间
禁用栈轨迹：
-XX:-StackTraceInThrowable 默认true
影响代码的弊端导致栈轨迹无法分析异常造成的意外。
日志
- GC日志，该日志可以定向到一个单独的文件中，文件大小由JVM管理
- HTTP服务器生成访问日志，每当有请求时更新。对于服务器上运行的任何测试，关闭日志会提升性能。
- 应用程序日志：
1.在日志数据和日志级别之间找到平衡
2.使用细粒度的日志记录器，类粒度和一组类的粒度记录
3.无作用代码中使用日志开关处理日志