Rick的专栏

主要解决的问题依赖的第三方系统不稳定等情况，影响开发和测试流程UI测试,压力测试等去除IO操作目前市场上集几种Mock方案以及分析在代码中Coding代码逻辑。使用网络代理，将服务代理到指定服务器（JVM Proxy参数）。修改注册中心，将相应的服务地址修改到Mock服务。使用JavaAgent 修改字节码，将相应的IO的地方修改到某些地方。分析现有的主流Mock方案有上面的列出几种，尽管可以达到Mock的目的，但是存在和现有业务代码耦合性大，功能匮乏，对mock掌控力能力弱等

分享一下之前写的Class 文件解析的工具。Gom:https://github.com/LavGo/gomgo get -u github.com/LavGo/gomgo install github.com/LavGo/gomgom Xjre="ClassFile path"

try-with-resource语法try(xxxStream is=new xxxxStream()){ return is.xxx;}try-with语法实际上就是 try-finally对于流处理的一个语法糖，会在try的代码块执行完毕后自动添加Finally方法块，并调用流的Close方法。这么看来使用try-with-resources来处理gzip流并没有问题。使用try-with 处理gzip流问题gzip会在close方法中调用finish方法把结果输出。 try

前文一路上看见晦涩难懂的ASM，小巧可人的Javassist。直到遇见了ByteBuddy才知世上竟有如此的冷艳简洁。JavaAgent从Jdk1.5开始Java开始支持Java Agent特性，可以通过premain方法，在Class字节码加载进虚拟机之前对底层的字节码进行修改。从而达到可以自定义特性的功能。给Aop的实现提供了一种更加简洁的方式。ByteBuddy字节码修改工具貌似从Java的诞生就一直存在，一开始的ASM，后来可以通过人类可以理解的方式修改字节码的Javassist，到现在的

一. 背景今天无心写代码，整理下文章看。应用对于第三方的依赖较多，由于第三方接口测试环境可靠性不高，容易导致测试人员测试堵塞；需要特定场景的数据，但是依赖相对复杂，伪造数据的成本较高等情况，对于接口，数据库，redis等Mock的需求还是比较大的。目前公司内部不同部门有多套Mock方案，但是都没有摆脱对代码的侵入，可扩展性不高。基于目前大部分服务已经是Java技术栈的前提情况下，通过JavaAgent修改字节码的方式达到Mock的目的的条件逐渐成熟，虽然该方案开发入门较高，但从可维护，推广简易，成本效益等

1.java处理word是个大大的坑，无论是poi还是Java2word 都不是尽善尽美。2.poi只能进行简单读操作，Java2word需要调用系统的com接口，系统机必须安装office和动态链接库。3.word从2003版本就可以保存为xml格式，通过操作xml可以满足我们的基本需求。package com.evaluationinfo.service;import java.

一.HotSpot虚拟机分析 1.HotSpot官方是32位架构，虚拟机具有自己的指令集，由于java是解释执行的，程序在运行过程中并不是运行机器的机器指令，而是运行虚拟机内部自己的指令集，然后通过不同架构体系的虚拟机运行各个机器平台的的指令集，使Java程序变现为对外的一致性和跨平台性； 2.hotspot内存分为全局区和线程区，全局区分为方法区，主要存储静态变量，代码，常量等在程序运行过程中

G1收集器一. 名词解释MetaSpace 在Java8之后取代永久代方法区的内存部分，NativeMemoryMixed GC Event 所有Young Region和一部分Old Region的混合GC时间。Reclaimable G1 为了能够回收，创建了一系列专门用于对象回收的Region，存放在链表中，只包含存活率小于-XX:G1MixedGCLIveThr...