记一次GRPC使用报错排查

　　项目一直使用grpc作为服务交互程序，其中我负责的java模块第一次引用该框架；当框架搭建好后，建立客户端代码，报错：

Runable Error:
java.lang.IllegalAccessError: tried to access field XXXXXXXXXXXXXXXXXXXXXX
    at com.scut.fan.infrastructure.ftree.NewRequest$getMemoriedcount(.java:142)

　　首先我们看下该异常的信息：

package java.lang;

/**
 * Thrown if an application attempts to access or modify a field, or
 * to call a method that it does not have access to.
 * <p>
 * Normally, this error is caught by the compiler; this error can
 * only occur at run time if the definition of a class has
 * incompatibly changed.
 *
 * @author  unascribed
 * @since   1.0
 */
public class IllegalAccessError extends IncompatibleClassChangeError {
    private static final long serialVersionUID = -8988904074992417891L;

    /**
     * Constructs an <code>IllegalAccessError</code> with no detail message.
     */
    public IllegalAccessError() {
        super();
    }

    /**
     * Constructs an <code>IllegalAccessError</code> with the specified
     * detail message.
     *
     * @param   s   the detail message.
     */
    public IllegalAccessError(String s) {
        super(s);
    }
}

　　通常我们定位问题最好的方法是先了解异常的javadoc，异常名称最能体现大方向，根据文档我们可以知道，当你没有权限访问一个field或者方法的时候，通常就会报这个异常，什么是没有权限呢？第一是修饰符问题，如果是protected，那么子类外不得引用；default修饰，那么包外不能引用；通常该类错误在编译时期就能被发现，如果是运行时期，那么通常是该类发生了不可兼容性的变更，那么我是否很顺利的修改完了Bug呢？

　　后来我去查看了GetMemoriedcount方法的类A，发现其中访问的memoriedcount成员变量就是定位错误的地方，也就是访问了该成员导致的illegalAcessError，而该成员是其A所继承的grpc框架级父类的成员，我进入该父类继续查看，发现该成员是Protected，没错啊，子类访问应该不会有问题，就算有问题，也是编译器报错，顿时我就开始苦恼；

可能性1—包冲突：

　　在网上看了很多方法，都说是包冲突，版本不对等等问题，其实深入到实质，包冲突也就是访问修饰符错误，因为有些包的版本就让你很崩溃，看个例子：ehcache-1.1.jar和ehcache-1.2.3.jar这两个包就有某个类同一字断不同访问修饰符的问题；

可能性2—内部类类加载：

　　也就是两个class文件，第一个A，第二个A$a；会导致价值不全的问题，我使用grpc在generalcode的时候也打包成单一问题，存在大部分内部类，所以我重新生产一次代码，这次我不用内部类，生成了几十个文件，可是最终依旧没解决问题，附加grpc不实用内部类的proto文件配置：

syntax = "proto3";

option java_multiple_files = true;  //这里决定是否使用内部类编译成单个源文件
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";

可能性3—类加载器：

　　不同类加载器无法连调，我还没做过实验；但我把这两者的ClassLoader打印，都一样；

突破：

　　因为我使用的是Maven管理依赖，所以我突然想起，这样会导致一个很严重的问题，就是编译的时候你依赖的包存在就能编译通过，但是Maven管理后，同包，也就是包冲突的话Maven只会使用一个包，所以如果包冲突而Maven丢弃你编译依赖的包的话就可能报错，然后我马上建立新项目，仅依赖需要的包，而不是在旧项目的POM文件中使用，发现顺利进行了RPC，最好我花了好长时间才找到一个隐藏的WebLibrary下的一个GRPC包，去掉，解决问题；

　　这是我第二次被Maven搞死了，不过也不能管Maven的类解析机制，怪我维护的项目多个前辈，这依赖是在太乱了