RPC 调用

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

• 分析源代码，基本原理如下：
• 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 ( ）方法继续执行就能拿到调用结果了），至此，整个过程结束

• 当前线程怎么让它暂停，等结果回来后，再向后执行？
• 先生成一个对象obj ，在一个全局 map 里 put ( 1D obj ）存放起来，再用synchronized获取obj锁，再调用obj.wait()让当前线程处于等待状态，然后另一消息监听线程等到服务端结果来了后，再 map.get （ID ）找到 obj ，再用 synchronized获取obj 锁，再调用obj.notifyAll唤配前面处于等待状态的线程
• Socket 通信是一个全双工的方式，如果有多个线程同时进行 远程方法调用 ，这时建立在client server之间的socket连接上会有很多双方发送的消息有传递，前后顺序也可能是乱七八嘈的，server处理完结果后，将结果消息发送给 client, client收到很多消息，怎么知道消息结果是原先哪个线程调用的? 使用一个ID ，让其唯一，然后传递给服务端，再服务端又回传回来，这样就知道结果是原先哪个线程的了

对Java技术，架构技术感兴趣的同学，可以关注我然后私信回复我”面试“即可获得免费的资料。

GC垃圾回收

大多数刚创建的对象会被分配在Eden区，当Eden区满的时候，执行Minor GC，将消亡的对象清理掉，并将剩余的对象复制到一个存活区Survivor0，当Survivor0也满的时候，将其中仍然活着的对象直接复制到Survivor1，以后Eden区执行Minor GC后，就将剩余的对象添加Survivor1，当两个存活区切换了几次（HotSpot虚拟机默认15次，用-XX:MaxTenuringThreshold控制，大于该值进入老年代）之后，仍然存活的对象将被复制到老年代

年轻代收集器

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

老年代收集器

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

CMS收集器

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

垃圾回收算法实现

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

对Java技术，架构技术感兴趣的同学，可以关注我然后私信回复我”面试“即可获得免费的资料。