1.哪些内存需要回收
2.什么时候回收
3.如何回收
内存动态分配
内存的回收技术
目的：
排查内存溢出
内存泄漏问题
主要讨论的是堆区
pc\虚拟机栈、本地方法栈 和线程相关
栈帧跟随方法 具有确认性
1.判断哪些对象还活着
引用计数法
优点：容易实现
缺点：循环依赖
A引用B B引用A
可达性分析
通过引用链
当一个对象没有任何引用链gc不可达 证明不可用
在JAVA中可做为GC roots对象包括
虚拟机栈中引用的对象（栈帧中的本地变量表）
方法区类静态属性引用的对象
方法区中常量引用的对象
jni引用的对象
引用：
refrence类型存储的类型是另外一块的地址 就认为该块儿是一个引用
扩展
强引用 强引用存在永远不会回收
软引用 有用非必须内存溢出之前会回收
弱引用 非必须 只能存在到下次gc之前
虚引用 无法通过虚引用获得实例 在这个对象回收时收到一个系统通知
2.清理时间
两次标记
第一次标记 赛选 1有没有必要执行finalize 条件 gc 调过 或者没有覆盖
有必要 放在Fqueue 稍后有一个Finalizer线程执行 并不能保证执行结束 原因？？ 最后一次机会
第一次finalize有机会自救
第二次标记
而一个对象的finliza只会被就一次
finalize不推荐用来自救
方法区 在方法区垃圾回收性价比低
新生代一次回收70-90
方法区 废弃的常量 无用的类
废弃常量 是否有对象引用它
无用类 1.该类的实例都已经被回收 2.加载的classloader已经被回收 3.没有任何地方被引用
虚拟机提供参数控制
在ByteCode框架有用
3.垃圾收集算法
Mark-Sweep
特点：效率低 内存碎片
复制算法
分块 标记 移动
适用于存活率较低 占用内存较小的
商业 分块 Eden survior
每次使用 90
生命时间长的 分配担保
标记整理
伴随着移动
分代收集
HotSpot
枚举根节点************
安全点************
安全区域****************
垃圾收集器
是具体实现
HotSpot的提供
CMS 目的：获取最短回收停顿时间 基于标记清除
缺点：
1.对cpu资源敏感
2.无法浮动垃圾
3.内存碎片
G1 并行并发 分带收集 空间整合 可预测停顿
原理把内存化整为零
内存分配和回收策略
大对象直接进OLd区域
长期存活进old区 age计数器
MinorGC 新生代gc
各种垃圾收集器之间的比较
https://blog.csdn.net/tjiyu/article/details/53983650
虚拟机类的加载机制
双亲委派加载
MajorGC FullGC 比较慢
Tomcat的类的加载机制
OSGI
字节码生成技术和动态带来
Retrotranslator
自己动手实现远程执行功能
优化没看
Java语言中的线程安全
代码本身封装了所有安全保障性的手段
调用者无需关心多线程
级别
不可变
调用者无需采用任何线程安全保护措施
final 没有this引用逃逸
比如String 它的subString replace contant 都是一个新构建的对象
Integer也是 状态不变
枚举类型
Numbei子类是
原子类不是
绝对线程安全
Vector并不是一个绝对安全的
相对的线程安全
要保证线程的操作是线程安全的 在调用时无需保障措施
线程兼容
对象本身不安全调用段正确的使用同步手段
线程对立
调用段是否采用同步措施都无法保证安全
如何保证线程安全
1.互斥同步
悲观的并发策略
无论是否竞争都加锁
互斥是同步的一种手段 临界区 互斥量 信号量
sychronized编译之后前后形成monitorenter o
执行monitor指令要先尝试获取对象的锁
如果获取失败要进行阻塞等待直到对象锁被另外一个线程释放
sychronized特点1可重入
原生语法的互斥锁
阻塞或者唤醒操作系统帮忙完成 线程状态切换 重量级的操作、
虚拟机自身的优化 自旋锁
JUC ReentrantLock
API层面的互斥锁 lock/unlock配合try/finally语句来完成
高级特性
1.等待可中断 正在等待可放弃等待做其他事
2.可实现公平锁
按照申请锁的顺序依次获取锁
3.锁可以绑定多个条件
jdk1.6有了很大的优化
虚拟机优化了狠多不需要的加锁
状态切换
维护锁计数器
是否需要唤醒
非阻塞同步
基于冲突检测的乐观并发锁
如果发生冲突 则补偿措施 cas 大多数不会把线程挂起
需要依赖硬件 tat fai sweep cas(cmpxchg casa ) ll/sc
CAS指令 3个操作数 v a b
该操作由Unsafe里的compareAndSwap 几个方法包装提供 虚拟机内部特殊处理
Unsafe只有启动内加载器才能访问 只能通过JUC原子类 或者反射调用
有一个漏洞 原子引用类 AtomicStampedReference 它可以通过控制变量值的版本保证CAS正确性 鸡肋
无同步方案
如果不存在共享数据
可重入代码 在代码执行时被打断
不依赖堆上的数据和公共资源 状态量参数传入 不调用非可重入方法
返回值可预测
线程本地存储 可见范围在一个线程内
应用：大部分的生产者消费者架构
web交互模型中一个请求对应一个服务器线程 线程本地存储
ThreadLocal 可以实现线程的本地存储
锁的优化
适应性自旋
锁消除
锁粗化
轻量级锁
无竞争的情况下使用cas
传统的互斥量
在没有竞争下减少互斥量
偏向锁
自旋锁
- 背景：互斥同步对性能最大的影响是阻塞，挂起和恢复线程都需要转入内核态中完成；并且通常情况下，共享数据的锁定状态只持续很短的一段时间，为了这很短的一段时间进行上下文切换并不值得。
- 原理：当一条线程需要请求一把已经被占用的锁时，并不会进入阻塞状态，而是继续持有CPU执行权等待一段时间，该过程称为『自旋』。
- 优点：由于自旋等待锁的过程线程并不会引起上下文切换，因此比较高效；
- 缺点：自旋等待过程线程一直占用CPU执行权但不处理任何任务，因此若该过程过长，那就会造成CPU资源的浪费。
- 自适应自旋：自适应自旋可以根据以往自旋等待时间的经验，计算出一个较为合理的本次自旋等待时间。
锁清除
编译器会清除一些使用了同步，但同步块中没有涉及共享数据的锁，从而减少多余的同步。
锁粗化
若有一系列操作，反复地对同一把锁进行上锁和解锁操作，编译器会扩大这部分代码的同步块的边界，从而只使用一次上锁和解锁操作。
轻量级锁
- 本质：使用CAS取代互斥同步。
- 背景：『轻量级锁』是相对于『重量级锁』而言的，而重量级锁就是传统的锁。
- 轻量级锁与重量级锁的比较：
- 重量级锁是一种悲观锁，它认为总是有多条线程要竞争锁，所以它每次处理共享数据时，不管当前系统中是否真的有线程在竞争锁，它都会使用互斥同步来保证线程的安全；
- 而轻量级锁是一种乐观锁，它认为锁存在竞争的概率比较小，所以它不使用互斥同步，而是使用CAS操作来获得锁，这样能减少互斥同步所使用的『互斥量』带来的性能开销。
- 实现原理：
- 对象头称为『Mark Word』，虚拟机为了节约对象的存储空间，对象处于不同的状态下，Mark Word中存储的信息也所有不同。
- Mark Word中有个标志位用来表示当前对象所处的状态。
- 当线程请求锁时，若该锁对象的Mark Word中标志位为01（未锁定状态），则在该线程的栈帧中创建一块名为『锁记录』的空间，然后将锁对象的Mark Word拷贝至该空间；最后通过CAS操作将锁对象的Mark Word指向该锁记录；
- 若CAS操作成功，则轻量级锁的上锁过程成功；
- 若CAS操作失败，再判断当前线程是否已经持有了该轻量级锁；若已经持有，则直接进入同步块；若尚未持有，则表示该锁已经被其他线程占用，此时轻量级锁就要膨胀成重量级锁。
- 前提：轻量级锁比重量级锁性能更高的前提是，在轻量级锁被占用的整个同步周期内，不存在其他线程的竞争。若在该过程中一旦有其他线程竞争，那么就会膨胀成重量级锁，从而除了使用互斥量以外，还额外发生了CAS操作，因此更慢！
偏向锁
- 作用：偏向锁是为了消除无竞争情况下的同步原语，进一步提升程序性能。
- 与轻量级锁的区别：轻量级锁是在无竞争的情况下使用CAS操作来代替互斥量的使用，从而实现同步；而偏向锁是在无竞争的情况下完全取消同步。
- 与轻量级锁的相同点：它们都是乐观锁，都认为同步期间不会有其他线程竞争锁。
- 原理：当线程请求到锁对象后，将锁对象的状态标志位改为01，即偏向模式。然后使用CAS操作将线程的ID记录在锁对象的Mark Word中。以后该线程可以直接进入同步块，连CAS操作都不需要。但是，一旦有第二条线程需要竞争锁，那么偏向模式立即结束，进入轻量级锁的状态。
- 优点：偏向锁可以提高有同步但没有竞争的程序性能。但是如果锁对象时常被多条线程竞争，那偏向锁就是多余的。
- 偏向锁可以通过虚拟机的参数来控制它是否开启。
锁的膨胀
消除无竞争下同步原语
偏向于第一个获得它的线程 该锁没有被其他线程获取 则 持有偏向锁的线程永不加锁