【Java】 DirectByteBuffer堆外内存回收
PhantomReference虚引用
在分析堆外内存回收之前,先了解下PhantomReference
虚引用。
PhantomReference
需要与ReferenceQueue
引用队列结合使用,在GC进行垃圾回收的时候,如果发现一个对象只有虚引用在引用它,则认为该对象需要被回收,会将引用该对象的虚引用加入到与其关联的ReferenceQueue
队列中,开发者可以通过ReferenceQueue
获取需要被回收的对象,然后做一些清理操作,从队列中获取过的元素会从队列中清除,之后GC就可以对该对象进行回收。
虚引用提供了一种追踪对象垃圾回收状态的机制,让开发者知道哪些对象准备进行回收,在回收之前开发者可以进行一些清理工作,之后GC就可以将对象进行真正的回收。
来看一个虚引用的使用例子:
- 创建一个
ReferenceQueue
队列queue,用于跟踪对象的回收; - 创建一个obj对象,通过new创建的是强引用,只要强引用存在,对象就不会被回收;
- 创建一个虚引用
PhantomReference
,将obj对象和ReferenceQueue
队列传入,此时phantomReference里面引用了obj对象,并关联着引用队列queue; - 同样的方式创建另一个obj1对象和虚引用对象phantomReference1;
- 将obj置为NULL,此时强引用关系失效;
- 调用
System.gc()
进行垃圾回收; - 由于obj的强引用关系失效,所以GC认为该对象需要被回收,会将引用该对象的虚引用phantomReference对象放入到与其关联的引用队列queue中;
- 通过
poll
从引用队列queue中获取对象,可以发现会获取到phantomReference对象,poll
获取之后会将对象从引用队列中删除,之后会被垃圾回收器回收; - obj1的强引用关系还在,所以从queue中并不会获取到;
public static void main(String[] args) {
// 创建引用队列
ReferenceQueue<Object> queue = new ReferenceQueue<Object>();
// 创建obj对象
Object obj = new Object();
// 创建虚引用,虚引用引用了obj对象,并与queue进行关联
PhantomReference<Object> phantomReference = new PhantomReference<Object>(obj, queue);
// 创建obj1对象
Object obj1 = new Object();
PhantomReference<Object> phantomReference1 = new PhantomReference<Object>(obj1, queue);
// 将obj置为NULL,强引用关系失效
obj = null;
// 垃圾回收
System.gc();
// 从引用队列获取对象
Object o = queue.poll();
if (null != o) {
System.out.println(o.toString());
}
}
输出结果:
java.lang.ref.PhantomReference@277c0f21
Reference实例的几种状态
Active:初始状态,创建一个Reference类型的实例之后处于Active状态,以上面虚引用为例,通过new创建一个PhantomReference
虚引用对象之后,虚引用对象就处于Active状态。
Pending:当GC检测到对象的可达性发生变化时,会根据是否关联了引用队列来决定是否将状态更改为Pending或者Inactive,虚引用必须与引用队列结合使用,所以对于虚引用来说,如果它实际引用的对象需要被回收,垃圾回收器会将这个虚引用对象加入到一个Pending列表中,此时处于Pending状态。
同样以上面的的虚引用为例,因为obj的强引用关系失效,GC就会把引用它的虚引用对象放入到pending列表中。
Enqueued:表示引用对象被加入到了引用队列,Reference有一个后台线程去检测是否有处于Pending状态的引用对象,如果有会将引用对象加入到与其关联的引用队列中,此时由Pending转为Enqueued状态表示对象已加入到引用队列中。
Inactive:通过引用队列的poll
方法可以从引用队列中获取引用对象,同时引用对象会从队列中移除,此时引用对象处于Inactive状态,之后会被GC回收。
DirectByteBuffer堆外内存回收
在DirectByteBuffer
的构造函数中,在申请内存之前,先调用了Bits
的reserveMemory
方法回收内存,申请内存之后,调用Cleaner
的create
方法创建了一个Cleaner
对象,并传入了当前对象(DirectByteBuffer)和一个Deallocator
类型的对象:
class DirectByteBuffer extends MappedByteBuffer implements DirectBuffer {
private final Cleaner cleaner;
DirectByteBuffer(int cap) { // package-private
super(-1, 0, cap, cap);
boolean pa = VM.isDirectMemoryPageAligned();
int ps = Bits.pageSize();
long size = Math.max(1L, (long)cap + (pa ? ps : 0));
// 清理内存
Bits.reserveMemory(size, cap);
long base = 0;
try {
// 分配内存
base = unsafe.allocateMemory(size);
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(size, cap);
throw x;
}
unsafe.setMemory(base, size, (byte) 0);
if (pa && (base % ps != 0)) {
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
// 创建Cleader,传入了当前对象和Deallocator
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}
}
Cleaner
从名字上可以看出与清理有关,Bits
的reserveMemory
方法底层也是通过Cleaner
来进行清理,所以Cleaner是重点关注的类。
Deallocator
是DirectByteBuffer
的一个内部类,并且实现了Runnable接口,在run方法中可以看到对内存进行了释放,接下来就去看下在哪里触发Deallocator
任务的执行:
class DirectByteBuffer extends MappedByteBuffer implements DirectBuffer {
private static class Deallocator implements Runnable {
// ...
private Deallocator(long address, long size, int capacity) {
assert (address != 0);
this.address = address; // 设置内存地址
this.size = size;
this.capacity = capacity;
}
public void run() {
if (address == 0) {
// Paranoia
return;
}
// 释放内存
unsafe.freeMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
}
}
Cleaner
Cleaner
继承了PhantomReference
,PhantomReference
是Reference
的子类,所以Cleaner
是一个虚引用对象。
创建Cleaner
虚引用需要与引用队列结合使用,所以在Cleaner中可以看到有一个ReferenceQueue
,它是一个静态的变量,所以创建的所有Cleaner对象都会共同使用这个引用队列。
在创建Cleaner的create
方法中,处理逻辑如下:
- 通过构造函数创建了一个Cleaner对象,构造函数中的referent参数为
DirectByteBuffer
,thunk参数为Deallocator
对象,在构造函数中又调用了父类的构造函数完成实例化; - 调用add方法将创建的Cleaner对象加入到链表中,添加到链表的时候使用的是头插法,新加入的节点放在链表的头部,first成员变量是一个静态变量,它指向链表的头结点,创建的Cleaner都会加入到这个链表中;
创建后的Cleaner对象处于Active状态。
public class Cleaner extends PhantomReference<Object>{
// ReferenceQueue队列
private static final ReferenceQueue<Object> dummyQueue = new ReferenceQueue<>();
// 静态变量,链表的头结点,创建的Cleaner都会加入到这个链表中
static private Cleaner first = null;
// thunk
private final Runnable thunk;
public static Cleaner create(Object ob, Runnable thunk) {
if (thunk == null)
return null;
// 创建一个Cleaner并加入链表
return add(new Cleaner(ob, thunk));
}
private Cleaner(Object referent, Runnable thunk) {
super(referent, dummyQueue); // 调用父类构造函数,传入引用对象和引用队列
this.thunk = thunk; // thunk指向传入的Deallocator
}
private static synchronized Cleaner add(Cleaner cl) {
// 如果头结点不为空
if (first != null) {
// 将新加入的节点作为头结点
cl.next = first;
first.prev = cl;
}
first = cl;
return cl;
}
}
Cleaner调用父类构造函数时,最终会进入到父类Reference
中的构造函数中:
referent:指向实际的引用对象,上面创建的是DirectByteBuffer
,所以这里指向的是DirectByteBuffer
。
queue:引用队列,指向Cleaner
中的引用队列dummyQueue
。
public class PhantomReference<T> extends Reference<T> {
// ...
public PhantomReference(T referent, ReferenceQueue<? super T> q) {
super(referent, q); // 调用父类构造函数
}
}
public abstract class Reference<T> {
/* 引用对象 */
private T referent;
// 引用队列
volatile ReferenceQueue<? super T> queue;
Reference(T referent, ReferenceQueue<? super T> queue) {
this.referent = referent;
// 设置引用队列
this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
}
}
启动ReferenceHandler线程
Reference
中有一个静态方法,里面创建了一个ReferenceHandler
并设置为守护线程,然后启动了该线程,并创建了JavaLangRefAccess
对象设置到SharedSecrets
中:
public abstract class Reference<T> {
static {
ThreadGroup tg = Thread.currentThread().getThreadGroup();
for (ThreadGroup tgn = tg;
tgn != null;
tg = tgn, tgn = tg.getParent());
// 创建ReferenceHandler
Thread handler = new ReferenceHandler(tg, "Reference Handler");
// 设置优先级为最高
handler.setPriority(Thread.MAX_PRIORITY);
handler.setDaemon(true);
handler.start();
// 这里设置了JavaLangRefAccess
SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
@Override
public boolean tryHandlePendingReference() {
// 调用了tryHandlePending
return tryHandlePending(false);
}
});
}
}
ReferenceHandler
是Reference
的内部类,继承了Thread
,在run方法中开启了一个循环,不断的执行tryHandlePending
方法,处理Reference中
的pending
列表:
public abstract class Reference<T> {
private static class ReferenceHandler extends Thread {
// ...
ReferenceHandler(ThreadGroup g, String name) {
super(g, name);
}
public void run() {
while (true) {
// 处理pending列表
tryHandlePending(true);
}
}
}
}
Cleaner会启动一个优先级最高的守护线程,不断调用tryHandlePending来检测是否有需要回收的引用对象(还未进行真正的回收),然后进行处理。
处理pending列表
垃圾回收器会将要回收的引用对象放在Reference
的pending
变量中,从数据类型上可以看出pending
只是一个Reference
类型的对象,并不是一个list,如果有多个需要回收的对象,如何将它们全部放入pending
对象中?
可以把pengding看做是一个链表的头结点,假如有引用对象被判定需要回收,如果pengding为空直接放入即可,如果不为空,将使用头插法将新的对象加入到链表中,也就是将新对象的discovered指向pending对象,然后将pending指向当前要回收的这个对象,这样就形成了一个链表,pending指向链表的头结点。
在pending链表中的引用对象处于pending状态。
接下来看tryHandlePending
方法的处理逻辑:
如果pending不为空,表示有需要回收的对象,此时将pengding指向的对象放在临时变量
r
中,并判断是否是Cleaner类型,如果是将其强制转为Cleaner
,记录在临时变量c
中,接着更新pending的值为r的discovered,因为discovered中记录了下一个需要被回收的对象,pengding需要指向下一个需要被回收的对象;pending如果为NULL,会进入到else的处理逻辑,返回值为参数传入的waitForNotify的值。
判断
Cleaner
对象是否为空,如果不为空,调用Cleaner的clean方法进行清理;获取引用对象关联的引用队列,然后调用
enqueue
方法将引用对象加入到引用队列中;返回true;
public abstract class Reference<T> {
// 指向pending列表中的下一个节点
transient private Reference<T> discovered;
// 静态变量pending列表,可以看做是一个链表,pending指向链表的头结点
private static Reference<Object> pending = null;
static boolean tryHandlePending(boolean waitForNotify) {
Reference<Object> r;
Cleaner c;
try {
synchronized (lock) {
// 如果pending不为空
if (pending != null) {
// 获取pending执行的对象
r = pending;
// 如果是Cleaner类型
c = r instanceof Cleaner ? (Cleaner) r : null;
// 将pending指向下一个节点
pending = r.discovered;
// 将discovered置为空
r.discovered = null;
} else {
// 等待
if (waitForNotify) {
lock.wait();
}
return waitForNotify;
}
}
} catch (OutOfMemoryError x) {
Thread.yield();
// retry
return true;
} catch (InterruptedException x) {
// retry
return true;
}
if (c != null) {
// 调用clean方法进行清理
c.clean();
return true;
}
// 获取引用队列
ReferenceQueue<? super Object> q = r.queue;
// 如果队列不为空,将对象加入到引用队列中
if (q != ReferenceQueue.NULL) q.enqueue(r);
// 返回true
return true;
}
}
释放内存
在Cleaner
的clean方法中,可以看到,调用了thunk的run方法,前面内容可知,thunk指向的是Deallocator对象,所以会执行Deallocator的run方法,Deallocator的run方法前面也已经看过,里面会对DirectByteBuffer的堆外内存进行释放:
public class Cleaner extends PhantomReference<Object> {
public void clean() {
if (!remove(this))
return;
try {
// 调用run方法
thunk.run();
} catch (final Throwable x) {
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
if (System.err != null)
new Error("Cleaner terminated abnormally", x)
.printStackTrace();
System.exit(1);
return null;
}});
}
}
}
总结
Cleaner是一个虚引用,它实际引用的对象DirectByteBuffer如果被GC判定为需要回收,会将引用该对象的Cleaner加入到pending列表,ReferenceHandler线程会不断检测pending是否为空,如果不为空,就对其进行处理:
- 如果对象类型为Cleaner,就调用Cleaner的clean方法进行清理,Cleaner的clean方法又会调用Deallocator的run方法,里面调用了freeMemory方法对DirectByteBuffer分配的堆外内存进行释放;
- 将Cleaner对象加入到与其关联的引用队列中;
引用队列
ReferenceQueue
名字听起来是一个队列,实际使用了一个链表,使用头插法将加入的节点串起来,ReferenceQueue
中的head
变量指向链表的头节点,每个节点是一个Reference类型的对象:
public class ReferenceQueue<T> {
// head为链表头节点
private volatile Reference<? extends T> head = null;
}
Reference
中除了discovered变量之外,还有一个next变量,discovered指向的是处于pending状态时pending列表中的下一个元素,next变量指向的是处于Enqueued状态时,引用队列中的下一个元素:
public abstract class Reference<T> {
/* When active: 处于active状态时为NULL
* pending: this
* Enqueued: Enqueued状态时,指向引用队列中的下一个元素
* Inactive: this
*/
@SuppressWarnings("rawtypes")
Reference next;
/* When active: active状态时,指向GC维护的一个discovered链表中的下一个元素
* pending: pending状态时,指向pending列表中的下一个元素
* otherwise: 其他情况为NULL
*/
transient private Reference<T> discovered; /* used by VM */
}
enqueue入队
进入引用队列中的引用对象处于enqueue状态。
enqueue
的处理逻辑如下:
- 判断要加入的对象关联的引用队列,对队列进行判断,如果队列为空或者队列等于
ReferenceQueue
中的空队列ENQUEUED
,表示该对象之前已经加入过队列,不能重复操作,返回false,如果未加入过继续下一步; - 将对象所关联的引用队列置为
ENQUEUED
,它是一个空队列,表示节点已经加入到队列中; - 判断头节点是否为空,如果为空,表示链表还没有节点,将当前对象的next指向自己,如果头结点不为空,将当前对象的next指向头结点,然后更新头结点的值为当前对象(头插法插入链表);
- 增加队列的长度,也就是链表的长度;
public class ReferenceQueue<T> {
// 空队列
static ReferenceQueue<Object> ENQUEUED = new Null<>();
// 入队,将节点加入引用队列,队列实际上是一个链表
boolean enqueue(Reference<? extends T> r) {
synchronized (lock) {
// 获取关联的引用队列
ReferenceQueue<?> queue = r.queue;
// 如果为空或者已经添加到过队列
if ((queue == NULL) || (queue == ENQUEUED)) {
return false;
}
assert queue == this;
// 将引用队列置为一个空队列,表示该节点已经入队
r.queue = ENQUEUED;
// 如果头结点为空将下一个节点置为自己,否则将next置为链表的头结点,可以看出同样使用的是头插法将节点插入链表
r.next = (head == null) ? r : head;
// 更新头结点为当前节点
head = r;
// 增加长度
queueLength++;
if (r instanceof FinalReference) {
sun.misc.VM.addFinalRefCount(1);
}
lock.notifyAll();
return true;
}
}
}
poll出队
在调用poll
方法从引用队列中获取一个元素并出队的时候,首先对head头结点进行判空,如果为空表示引用队列中没有数据,返回NULL,否则调用reallyPoll
从引用队列中获取元素。
出队的处理逻辑如下:
获取链表中的第一个节点也就是头结点,如果不为空进行下一步;
如果头节点的下一个节点是自己,表示链表只有一个节点,头结点出队之后链表为空,所以将头结点的值更新为NULL;
如果头节点的下一个节点不是自己,表示链表中还有其他节点,更新head头节点的值为下一个节点,也就是next指向的对象;
将需要出队的节点的引用队列置为NULL,next节点置为自己,表示节点已从队列中删除;
引用队列的长度减一;
返回要出队的节点;
从出队的逻辑中可以看出,引用队列中的对象是后进先出的,poll出队之后的引用对象处于Inactive状态,表示可以被GC回收掉。
public class ReferenceQueue<T> {
/**
* 从引用队列中获取一个节点,进行出队操作
*/
public Reference<? extends T> poll() {
// 如果头结点为空,表示没有数据
if (head == null)
return null;
synchronized (lock) {
return reallyPoll();
}
}
@SuppressWarnings("unchecked")
private Reference<? extends T> reallyPoll() { 、 /* Must hold lock */
// 获取头结点
Reference<? extends T> r = head;
if (r != null) {
// 如果头结点的下一个节点是自己,表示链表只有一个节点,head置为null,否则head值为r的下一个节点,也就是next指向的对象
head = (r.next == r) ?
null :
r.next;
// 将引用队列置为NULL
r.queue = NULL;
// 下一个节点置为自己
r.next = r;
// 长度减一
queueLength--;
if (r instanceof FinalReference) {
sun.misc.VM.addFinalRefCount(-1);
}
// 返回链表中的第一个节点
return r;
}
return null;
}
}
reserveMemory内存清理
最开始在DirectByteBuffer的构造函数中看到申请内存之前会调用Bits的reserveMemory
方法,如果没有足够的内存,它会从SharedSecrets
获取JavaLangRefAccess
对象进行一些处理,由前面的内容可知,Reference
中的静态方法启动ReferenceHandler
之后,创建了JavaLangRefAccess
并设置到SharedSecrets
中,所以这里调用JavaLangRefAccess
的tryHandlePendingReference
实际上依旧调用的是Reference
中的tryHandlePending
方法。
在调用Reference
中的tryHandlePending
方法处理需要回收的对象之后,调用tryReserveMemory
方法判断是否有足够的内存,如果内存依旧不够,会调用` System.gc()触发垃圾回收,然后开启一个循环,处理逻辑如下:
判断内存是否充足,如果充足直接返回;
判断睡眠次数是否小于限定的最大值,如果小于继续下一步,否则终止循环;
调用tryHandlePendingReference处理penging列表中的引用对象,前面在处理pending列表的逻辑中可以知道,如果pending列表不为空,会返回true,tryHandlePendingReference也会返回true,此时意味着清理了一部分对象,所以重新进入到第1步进行检查;
如果pending列表为空,会返回参数中传入的waitForNotify的值,从JavaLangRefAccess的tryHandlePendingReference中可以看出这里传入的是false,所以会进行如下处理:
- 通过
Thread.sleep(sleepTime)
让当前线程睡眠一段时间,这样可以避免reserveMemory方法一直在占用资源; - 对睡眠次数加1;
- 通过
如果以上步骤处理之后还没有足够的空间会抛出抛出OutOfMemoryError异常;
reserveMemory方法的作用是保证在申请内存之前有足够的内存,如果没有足够的内存会进行清理,达到指定清理次数之后依旧没有足够的内存空间,将抛出OutOfMemoryError异常。
class Bits {
static void reserveMemory(long size, int cap) {
if (!memoryLimitSet && VM.isBooted()) {
maxMemory = VM.maxDirectMemory();
memoryLimitSet = true;
}
// 是否有足够内存
if (tryReserveMemory(size, cap)) {
return;
}
// 获取JavaLangRefAccess
final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();
// 调用tryHandlePendingReference
while (jlra.tryHandlePendingReference()) {
// 判断是否有足够的内存
if (tryReserveMemory(size, cap)) {
return;
}
}
// 调用gc进行垃圾回收
System.gc();
boolean interrupted = false;
try {
long sleepTime = 1;
int sleeps = 0;
// 开启循环
while (true) {
// 是否有足够内存
if (tryReserveMemory(size, cap)) {
return;
}
// 如果次数小于最大限定次数,终止
if (sleeps >= MAX_SLEEPS) {
break;
}
// 再次处理penging列表中的对象
if (!jlra.tryHandlePendingReference()) {
try {
// 睡眠一段时间
Thread.sleep(sleepTime);
sleepTime <<= 1;
sleeps++; // 睡眠次数增加1
} catch (InterruptedException e) {
interrupted = true;
}
}
}
// 抛出OutOfMemoryError异常
throw new OutOfMemoryError("Direct buffer memory");
} finally {
if (interrupted) {
// don't swallow interrupts
Thread.currentThread().interrupt();
}
}
}
}
public abstract class Reference<T> {
static {
// ...
// 这里设置了JavaLangRefAccess
SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
@Override
public boolean tryHandlePendingReference() {
// 调用tryHandlePending,这里waitForNotify参数传入的是false
return tryHandlePending(false);
}
});
}
}
参考
Java 源码剖析——彻底搞懂 Reference 和 ReferenceQueue
【Java】 DirectByteBuffer堆外内存回收的更多相关文章
- Java进程堆外内存(off heap)大小
一.使用ByteBuffer.allocateDirect分配的off heap内存大小 本机进程 在Jvisualvm中安装 Mbeans插件.然后查看java.nio/BufferPool/dir ...
- JAVA使用堆外内存导致swap飙高
https://github.com/nereuschen/blog/issues/29 堆内内存分析一般用Memory Analyzer Tool http://tivan.iteye.com/bl ...
- Java NIO 堆外内存与零拷贝
一.直接缓存 这个例子的区别就是 ByteBuffer.allocateDirect(512); 进入allocateDirect方法 进入DirectByteBuffer构造函数 Native方法: ...
- Netty之Java堆外内存扫盲贴
Java的堆外内存本来是高贵而神秘的东西,只在一些缓存方案的收费企业版里出现.但自从用了Netty,就变成了天天打交道的事情,毕竟堆外内存能减少IO时的内存复制,不需要堆内存Buffer拷贝一份到直接 ...
- Java堆外内存之三:堆外内存回收方法
一.JVM内存的分配及垃圾回收 对于JVM的内存规则,应该是老生常谈的东西了,这里我就简单的说下: 新生代:一般来说新创建的对象都分配在这里. 年老代:经过几次垃圾回收,新生代的对象就会放在年老代里面 ...
- Java堆外内存之六:堆外内存溢出问题排查
一.堆外内存组成 通常JVM的参数我们会配置 -Xms 堆初始内存 -Xmx 堆最大内存 -XX:+UseG1GC/CMS 垃圾回收器 -XX:+DisableExplicitGC 禁止显示GC -X ...
- cassandra 堆外内存管理
为什么需要堆外内存呢 单有一些大内存对象的时候,JVM进行垃圾回收时需要收集所有的这些对象的内存也.增加了GC压力.因此需要使用堆外内存. java 分配堆外内存 org.apache.cassand ...
- JVM源码分析之堆外内存完全解读
JVM源码分析之堆外内存完全解读 寒泉子 2016-01-15 17:26:16 浏览6837 评论0 阿里技术协会 摘要: 概述 广义的堆外内存 说到堆外内存,那大家肯定想到堆内内存,这也是我们 ...
- Netty堆外内存泄漏排查,这一篇全讲清楚了
上篇文章介绍了Netty内存模型原理,由于Netty在使用不当会导致堆外内存泄漏,网上关于这方面的资料比较少,所以写下这篇文章,专门介绍排查Netty堆外内存相关的知识点,诊断工具,以及排查思路提供参 ...
随机推荐
- (一)、数字图像处理(DIP)
1.什么是图像? 图像是人类视觉的基础,是自然景物的客观事实,是人类认识世界和人类本身的重要源泉:也可以说图像是客观对象的一种表示. '图'是物体反射或透射光的分布:'像'是人的视觉系统所接受的图,在 ...
- 后端统一处理返回前端日期LocalDateTime格式化去T,Long返回前端损失精度问题
一.前言 我们在实际开发中肯定会遇到后端的时间传到前端是这个样子的:2022-08-02T15:43:50 这个时候前后端就开始踢皮球了,!! 后端说:前端来做就可! 前端说:后端来做就可! 作为一名 ...
- 6. MGR状态监控 | 深入浅出MGR
GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源. 目录 1. 节点状态监控 2. MGR事务状态监控 3. 其他监控 4. 小结 参考资料.文档 免责声明 文章推荐: 关于 ...
- Sonatype Nexus3 搭建私有仓库
Nexus是Sonatype提供的仓库管理平台,Nuexus Repository OSS3能够支持Maven.npm.Docker.YUM.Helm等格式数据的存储和发布:并且能够与Jekins.S ...
- JDK数组阻塞队列源码深入剖析
JDK数组阻塞队列源码深入剖析 前言 在前面一篇文章从零开始自己动手写阻塞队列当中我们仔细介绍了阻塞队列提供给我们的功能,以及他的实现原理,并且基于谈到的内容我们自己实现了一个低配版的数组阻塞队列.在 ...
- React报错之React hook 'useState' is called conditionally
正文从这开始~ 总览 当我们有条件地使用useState钩子时,或者在一个可能有返回值的条件之后,会产生"React hook 'useState' is called conditiona ...
- Spring源码环境搭建
Spring源码在github上,地址是https://github.com/spring-projects/spring-framework/,选择5.3.x版本,直接从github上克隆项目网速很 ...
- 什么?WPF 不支持 SVG ?
什么?WPF 不支持 SVG ? 控件名:SharpVectors 作者:Elinam LLC (Japan) 项目地址: https://github.com/ElinamLLC/SharpVect ...
- ipv6临时地址
关闭ipv6临时地址 win+r输入cmd进入后输入代码 netsh interface ipv6 setprivacy state=disable 控制面板中找到网卡禁用后在启用 win+r输入cm ...
- 阿里云CentOS7安装K8S
1. 在阿里云山申请三台云服务器 1.1 环境准备 完成配置后的信息 服务器IP 操作系统 CPU 内存 硬盘 主机名 节点角色 172.18.119.145 centos7 2 4G 50G k8s ...