doc[protocol]: update document

protocol/README.md

@@ -53,13 +53,11 @@ memory：64g
 
 - Use Javassist bytecode to enhance the dynamic generation of serialization and deserialization functions for sequential
   execution, and sequential functions can be easily JIT compiled to achieve extreme performance
-- Natively integrated with netty's high-performance Byte Buf
+- Natively integrated with netty's high-performance ByteBuf, support Zero Copy
 - With primitive type collection, there is no boxing and unboxing, invalid GCs are avoided, and the performance is fast
   enough
-- Inherently thread-safe and lock-free; kryo forces each thread to have its own instance of Kryo, which is a heavy
-  design, especially in scenarios with many threads
-- No reflections, no unsafe operation; The use of objenesis in Kryo resulted in a lot of unsafe, and warnings when
-  running in Java 11
+- thread-safe and lock-free, without any performance loss in multi-threaded environment
+- No reflection, no unsafe operations, support GraalVM
 - Flattening the call depth of the method stack, and there is no performance penalty for nesting data structures, such
   as List<Set<Map<>>>; Comparing kryo and protobuf data structure nesting results in a performance penalty
 - There is no risk of vulnerability injection, only bytecode enhancement will be performed during initialization, and no

protocol/README_CN.md

@@ -45,10 +45,10 @@ cpu： i9900k
 ### Ⅳ. 为什么快
 
 - 使用Javassist字节码增强动态生成顺序执行的序列化和反序列化函数，顺序化的函数可以轻易的被JIT编译以达到极致的性能
-- 原生集成netty的高性能ByteBuf
+- 原生集成netty的高性能ByteBuf，支持Zero Copy
 - 使用primitive type collection，没有装箱和拆箱，避免了无效GC，性能也足够快
-- 天生线程安全并且无锁化；kryo强制要求每条线程都有自己的一个Kryo实例，这是一个比较重的设计，特别是线程比较多的场景
-- 没有反射，没有unsafe操作；对比kryo中使用objenesis导致大量unsafe，而且在Java11中运行会出现警告
+- 天生线程安全并且无锁化，多线程环境无任何性能损失
+- 没有反射，没有unsafe操作，只是GraalVM
 - 扁平化了方法栈的调用深度，数据结构嵌套没有任何性能损失，如List<Set<Map<>>>；对比kryo和protobuf数据结构嵌套会出现性能损失
 - 无漏洞注入风险，只有初始化时会进行字节码增强，后期不会再进行任何字节码的操作
 - 充分利用程序局部性原理，序列化器放在short[]数组中，对象序列化和反序列化只会查找一次序列化器