smallbirdnq的专栏

但是这个只是一个普通的Java工程，我们在Java web开发的今天大多数Java程序员都是通过SpringCloud及SpringBoot开启微服务或者单个应用的开发，我们最好通过springboot继承gRPC，这样一个工程既可以支持web开发，也可以支持gRPC协议通信。具体server端实现和client端实现完全可以参考大佬的examples，完全足够让你理解其实现的便捷性，你也可以按照其参考实现，提供maven和gradle两种构建方式。1.rpc-server pom.xml配置如下。

本次是通过Maven工具构建Java测试工程，需要将原本通过gradle构建的项目需要通过maven构建加入公司代码库，通过Maven构建涉及到接下来要介绍的插件，总是发现pom.xml编译不通过，看到网上都是千篇一律的插件配置，自己就是编译不通过，不知道大家有木有遇到，下面我将调试过程以及解决方案记录如下。1.定义proto文件因为是测试和官网一样，定义一个简单的hello.proto文件2.maven插件配置添加依赖添加插件。

GRADLE_USER_HOME：指定Gradle用户的主目录（如果未设置，则默认为$USER_HOME/.gradle）gradle 默认安装位置。

通过Full gc操作来触发回收堆外内存，不过我想先说的是堆外内存不会对gc造成什么影响(这里的System.gc除外)，但是堆外内存的回收其实依赖于我们的gc机制，首先我们要知道在java层面和我们在堆外分配的这块内存关联的只有与之关联的DirectByteBuffer对象了，它记录了这块内存的基地址以及大小，那么既然和gc也有关，那就是gc能通过操作DirectByteBuffer对象来间接操作对应的堆外内存了。所以在后面打代码中，会进行最多9次尝试，看是否有足够的可用堆外内存来分配堆外内存。

最初在看到Java AQS相关代码的时候发现Unsafe在加锁和释放锁时候使用，当时只是看了有这么一个Class，后来在Java并发编程java.util.concurrent包下经常看到，没有做过多深入研究，直到在Netty框架开发中涉及到了堆外内存（DirectoryByteBuffer）发现了Unsafe的奇妙之处，它避开了Java JVM 堆的内存管理，直接申请分配内存空间，不受JVM GC垃圾回收的限制。

为了提高性能，Netty重新设计了字节缓冲区ByteBuf，类似Java Nio的ByteBuffer，但工作方式略有区别，比后者更加灵活、高效。ByteBuf有几个重要属性：capacity：容量；0：缓冲区开始位置；readIndex：下一个读位置；writeIndex：下一个写位置；一个ByteBuf对象即可像byte数组一样工作，又可以像IO字节流一样工作。当前的可读数据区是[readIndex,writeIndex)；可写区是[writeIndex,capacity)；

本节我主要分析一下server端解析报文的一个过程，client当然也很重要，尤其在建立TCP连接和关闭连接需要严格控制，否则服务端会发现大量的CLOSE_WAIT（被动关闭连接）,甚至大量TIME_WAIT（主动关闭连接），关于这个处理之前的文章有讲解。读了ByteToMessageDecoder的部分源码，以及它的实现JsonObjectDecoder，那么如果我们自己实现一个Decoder该如何实现，这里提供三个思路给大家，有时间再补充代码。累加器的作用是解决tcp数据包中出现半包和粘包问题。

Java是获取不到对象的地址的，但是你可以获取hashcode，对象的hashcode在某种意义上就相当于对象的地址了，hashCode是用来在散列存储结构中确定对象的存储地址的。System.identityHashCode(Object)方法可以返回对象的内存地址,不管该对象的类是否重写了hashCode()方法。Object的hashCode()默认是返回内存地址的，但是hashCode()可以重写，所以hashCode()不能代表内存地址的不同。

jvm8参数配置

ParNew: 230534K->2665K(256256K), 0.0125008 secs] : 本次GC是ParNewGC，230534K->2665K是本次GC前后新生代的实际size，(256256K)是新生代容量，0.0125008 secs大约是本次GC在新生代的耗时，英文原文是"Duration for the collection w/o final cleanup"，不太懂啥意思。实际生产上，有时需要分析GC日志，检查GC回收有没有引起过多的系统暂停，特别是full GC。