Netty中的内存管理
通过之前的博客,大家可能已经知道整个gRPC是如何通信的了,因此对Netty也有了一定的了解,但是博主一直很困惑,Netty是如何控制内存的呢,完全异步化的世界里,各个Frame
都是独立的,其中的数据在某一时刻或者某一中间状态时也是安静的躺在内存里,等待处理,稍有不慎就会发生内存泄漏,Netty又是如何防止这些情况的呢,让我们从DirectByteBuffer
开始说起。
通过之前的博客,大家可能已经知道整个gRPC是如何通信的了,因此对Netty也有了一定的了解,但是博主一直很困惑,Netty是如何控制内存的呢,完全异步化的世界里,各个Frame
都是独立的,其中的数据在某一时刻或者某一中间状态时也是安静的躺在内存里,等待处理,稍有不慎就会发生内存泄漏,Netty又是如何防止这些情况的呢,让我们从DirectByteBuffer
开始说起。
学习过JAVA的同学,对引用一定不陌生,这篇博客主要是重温一下非常规的引用(强引用),因为后续准备研读一下 gRPC 使用堆外内存是如何管理内存进行 GC 的,因此整理一下基础知识。
根据 Wiki 对 Zero-copy 的定义:
“Zero-copy” describes computer operations in which the CPU does not perform the task of copying data from one memory area to another. This is frequently used to save CPU cycles and memory bandwidth when transmitting a file over a network.
前边我们讲了gRPC通信的模型,以及WriteQueue
还有Frame。哎?那我们最终看到的请求或者响应,都是已经序列化好的类啊?难道Netty
还能帮我转换成字节不成?如果一次通信的Frame过大,要分两个Frame发,怎么整?本篇会来介绍处理这些问题的类,MessageFrame
和MessageDeframer
。
经过前边两章,大家应该了解了gRPC中的网络相关的知识,但是真的要通讯起来,网络包、通讯流程、数据结构又是如何的呢?直接使用HTTP2进行通讯不就完事了?远没有那么简单,本文会从gRPC中的WriteQueue
出发,介绍一下gRPC中请求的封装结构,以及Frame的概念。下文所有的Frame,也叫帧,各位看官注意一下。
看过了第一篇gRPC的网络模型,相信大家已经对gRPC的网络模型有了一定的了解,今天博主会结合大名鼎鼎的Netty
,详细掰掰扯和数据交互密不可分的这些类,他们的区别和联系。
gRPC 一开始由 google 开发,是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。其内部使用Netty作为网络架构,但是Netty的使用姿势有千千万万种,究竟gRPC是如何与Netty进行融合,并且处理通信请求的,本篇博客会讲解讲解。
在上一篇博客中,博主遇到了一个死锁的案例。但是真的要弄清楚MYSQL中的锁,确实是一件很复杂的事情。这里我只针对InnoDB引擎,介绍一些MYSQL中的锁,主要为了给各位提供一个解决死锁的思路。(当然,如果不了解MYSQL索引原理的同学,还是先了解一些MYSQL索引的原理)。
MYSQL中为了保证隔离级别的有效性,以及插入数据的正确性,加入了一些锁机制,比如间隙锁(GAP),排他锁,共享锁,插入意向锁等等,锁的粒度也有很多。今天谈到的一个问题是有关于数据库死锁的问题,大家在看之前最好能先看看MYSQL中的一些锁机制,方便了解。
Spring中也是有一些一不注意就会踩到的坑。本屌原来在支付做过一段时间,也遇到过Spring中事务失效的问题。前几天写代码,又发现了一个空指针问题,闲来无事,写一写,方便后人踩坑后有个思路。