RPC调用与GC垃圾回收

• 多个服务协同完成一次业务时，由于业务约束（如红包不符合使用条件、账户余额不足等）、系统故障（如网络或系统超时或中断、数据库约束不满足等），都可能造成服务处理过程在任何一步无法继续，使数据处于不一致的状态。传统的基于数据库本地事务的解决方案只能保障单个服务的一次处理具备原子性、隔离性、一致性与持久性，但无法保障多个分布服务间处理的一致性

• 分析源代码，基本原理如下：
  • client 一个线程调用远程接口，生成一个唯一的 ID （比如一段随机字符串，UUID 等） , Dubbo 是使用 AtomicLong 从 0 开始累计数字的
  • 将打包的方法调用信息（如调用的接口名称，方法名称，参数值列表等），和处理结果的回调对象 call back ，全都封装在一起，组成一个对象 0bject
  • 向专门存放调用信息的全局 ConcurrentHashMap 里面 put ( ID , object )
  • 将 ID 和打包的方法调用信息封装成一对象 connRequest ，使用 Iosession.write ( connRequest ）异步发送出去
  • 当前线程再使用call back 的get()方法试图获取远程返回的结果，在 get()内部，则使用 Synchronized 获取回调对象 caIlback 的锁，再先检测是否已经获取到结果，如果没有，然后调用 callbaCk 的 wait()方法，释放 callback 上的锁，让当前线程处于等待状态
  • 服务端接收到请求并处理后，将结果（此结果中包含了前面的 ID ，即回传）发送给客户端，客户端 socket连接上专门监听消息的线程收到消息，分析结果，取到 ID ，再从前面的ConcurrentHashMap里面 get(ID) ，从而找到 callback ，将方法调用结果设置到 callback 对象里
  • 监听线程接着使用 synchronized 获取回调对象 callback 的锁（因为前面调用过 wait ( ) ，那个线程已释放 callback 的锁了），再 notlfyAll ( ) ，唤醒前面处于等待状态的线程继续执行（ call back 的 get ( ）方法继续执行就能拿到调用结果了），至此，整个过程结束

年轻代收集器

• Serial收集器：“停止-复制”算法，单线程，进行垃圾收集时必须暂停其他线程的所有工作
• ParNew收集器：Serial收集器的多线程版本，“停止-复制”算法，多线程
• Parallel Scavenge收集器：”停止-复制“算法，并行的多线程收集器，可控制的吞吐量

老年代收集器

• Serial Old：Serial收集器的老年代版本，同样是一个单线程收集器，使用“标记-整理”算法
• Parallel Old收集器：Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法
• CMS收集器：CMS(Conrrurent Mark Sweep)收集器是以获取最短回收停顿时间为目标的收集器,使用"标记-清除"算法

CMS收集器

• 初始标记：标记GCRoots能直接关联到的对象，时间很短
• 并发标记：进行GCRoots Tracing（可达性分析）过程，时间很长
• 重新标记：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，时间较长
• 并发清除：清除未标记(无关联引用)的对象，伴随着用户线程的执行，清除后会产生浮动垃圾
• 优缺点：对CPU资源非常敏感，可能会导致应用程序变慢，吞吐率下降，无法处理浮动垃圾，采用的“标记-清除”算法，会产生大量的内存碎片

垃圾回收算法实现

• 停止-复制算法：将内存分为两块，当其中一块内存用完了，将还存活着的对象复制到另一块中，再将使用过的内存一次性清理掉
• 标记-清除算法：首先标记出所有需要回收的对象，标记完成后统一回收所有被标记的对象
• 标记-整理算法：让所有存活对象都向一端移动，然后直接清理掉边界以外的内存