PhantomReference虚引用

在分析堆外内存回收之前,先了解下PhantomReference虚引用。

PhantomReference需要与ReferenceQueue引用队列结合使用,在GC进行垃圾回收的时候,如果发现一个对象只有虚引用在引用它,则认为该对象需要被回收,会将引用该对象的虚引用加入到与其关联的ReferenceQueue队列中,开发者可以通过ReferenceQueue获取需要被回收的对象,然后做一些清理操作,从队列中获取过的元素会从队列中清除,之后GC就可以对该对象进行回收。

虚引用提供了一种追踪对象垃圾回收状态的机制,让开发者知道哪些对象准备进行回收,在回收之前开发者可以进行一些清理工作,之后GC就可以将对象进行真正的回收。

来看一个虚引用的使用例子:

  1. 创建一个ReferenceQueue队列queue,用于跟踪对象的回收;
  2. 创建一个obj对象,通过new创建的是强引用,只要强引用存在,对象就不会被回收;
  3. 创建一个虚引用PhantomReference,将obj对象和ReferenceQueue队列传入,此时phantomReference里面引用了obj对象,并关联着引用队列queue;
  4. 同样的方式创建另一个obj1对象和虚引用对象phantomReference1;
  5. 将obj置为NULL,此时强引用关系失效;
  6. 调用 System.gc()进行垃圾回收;
  7. 由于obj的强引用关系失效,所以GC认为该对象需要被回收,会将引用该对象的虚引用phantomReference对象放入到与其关联的引用队列queue中;
  8. 通过poll从引用队列queue中获取对象,可以发现会获取到phantomReference对象,poll获取之后会将对象从引用队列中删除,之后会被垃圾回收器回收;
  9. 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的构造函数中,在申请内存之前,先调用了BitsreserveMemory方法回收内存,申请内存之后,调用Cleanercreate方法创建了一个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从名字上可以看出与清理有关,BitsreserveMemory方法底层也是通过Cleaner来进行清理,所以Cleaner是重点关注的类。

DeallocatorDirectByteBuffer的一个内部类,并且实现了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继承了PhantomReferencePhantomReferenceReference的子类,所以Cleaner是一个虚引用对象

创建Cleaner

虚引用需要与引用队列结合使用,所以在Cleaner中可以看到有一个ReferenceQueue,它是一个静态的变量,所以创建的所有Cleaner对象都会共同使用这个引用队列

在创建Cleaner的create方法中,处理逻辑如下:

  1. 通过构造函数创建了一个Cleaner对象,构造函数中的referent参数为DirectByteBuffer,thunk参数为Deallocator对象,在构造函数中又调用了父类的构造函数完成实例化;
  2. 调用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);
}
});
}
}

ReferenceHandlerReference的内部类,继承了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列表

垃圾回收器会将要回收的引用对象放在Referencepending变量中,从数据类型上可以看出pending只是一个Reference类型的对象,并不是一个list,如果有多个需要回收的对象,如何将它们全部放入pending对象中?

可以把pengding看做是一个链表的头结点,假如有引用对象被判定需要回收,如果pengding为空直接放入即可,如果不为空,将使用头插法将新的对象加入到链表中,也就是将新对象的discovered指向pending对象,然后将pending指向当前要回收的这个对象,这样就形成了一个链表,pending指向链表的头结点。

在pending链表中的引用对象处于pending状态。

接下来看tryHandlePending方法的处理逻辑:

  1. 如果pending不为空,表示有需要回收的对象,此时将pengding指向的对象放在临时变量r中,并判断是否是Cleaner类型,如果是将其强制转为Cleaner,记录在临时变量c中,接着更新pending的值为r的discovered,因为discovered中记录了下一个需要被回收的对象,pengding需要指向下一个需要被回收的对象;

    pending如果为NULL,会进入到else的处理逻辑,返回值为参数传入的waitForNotify的值。

  2. 判断Cleaner对象是否为空,如果不为空,调用Cleaner的clean方法进行清理

  3. 获取引用对象关联的引用队列,然后调用enqueue方法将引用对象加入到引用队列中

  4. 返回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是否为空,如果不为空,就对其进行处理:

  1. 如果对象类型为Cleaner,就调用Cleaner的clean方法进行清理,Cleaner的clean方法又会调用Deallocator的run方法,里面调用了freeMemory方法对DirectByteBuffer分配的堆外内存进行释放;
  2. 将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的处理逻辑如下:

  1. 判断要加入的对象关联的引用队列,对队列进行判断,如果队列为空或者队列等于ReferenceQueue中的空队列ENQUEUED,表示该对象之前已经加入过队列,不能重复操作,返回false,如果未加入过继续下一步;
  2. 将对象所关联的引用队列置为ENQUEUED,它是一个空队列,表示节点已经加入到队列中;
  3. 判断头节点是否为空,如果为空,表示链表还没有节点,将当前对象的next指向自己,如果头结点不为空,将当前对象的next指向头结点,然后更新头结点的值为当前对象(头插法插入链表);
  4. 增加队列的长度,也就是链表的长度;
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从引用队列中获取元素。

出队的处理逻辑如下:

  1. 获取链表中的第一个节点也就是头结点,如果不为空进行下一步;

  2. 如果头节点的下一个节点是自己,表示链表只有一个节点,头结点出队之后链表为空,所以将头结点的值更新为NULL;

    如果头节点的下一个节点不是自己,表示链表中还有其他节点,更新head头节点的值为下一个节点,也就是next指向的对象;

  3. 将需要出队的节点的引用队列置为NULL,next节点置为自己,表示节点已从队列中删除;

  4. 引用队列的长度减一;

  5. 返回要出队的节点;

从出队的逻辑中可以看出,引用队列中的对象是后进先出的,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中,所以这里调用JavaLangRefAccesstryHandlePendingReference实际上依旧调用的是Reference中的tryHandlePending方法。

在调用Reference中的tryHandlePending方法处理需要回收的对象之后,调用tryReserveMemory方法判断是否有足够的内存,如果内存依旧不够,会调用` System.gc()触发垃圾回收,然后开启一个循环,处理逻辑如下:

  1. 判断内存是否充足,如果充足直接返回;

  2. 判断睡眠次数是否小于限定的最大值,如果小于继续下一步,否则终止循环;

  3. 调用tryHandlePendingReference处理penging列表中的引用对象,前面在处理pending列表的逻辑中可以知道,如果pending列表不为空,会返回true,tryHandlePendingReference也会返回true,此时意味着清理了一部分对象,所以重新进入到第1步进行检查;

    如果pending列表为空,会返回参数中传入的waitForNotify的值,从JavaLangRefAccess的tryHandlePendingReference中可以看出这里传入的是false,所以会进行如下处理:

    • 通过 Thread.sleep(sleepTime)让当前线程睡眠一段时间,这样可以避免reserveMemory方法一直在占用资源;
    • 对睡眠次数加1;
  4. 如果以上步骤处理之后还没有足够的空间会抛出抛出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);
}
});
}
}

参考

Reference源码解析

一文读懂java中的Reference和引用类型

Java 源码剖析——彻底搞懂 Reference 和 ReferenceQueue

【Java】 DirectByteBuffer堆外内存回收的更多相关文章

  1. Java进程堆外内存(off heap)大小

    一.使用ByteBuffer.allocateDirect分配的off heap内存大小 本机进程 在Jvisualvm中安装 Mbeans插件.然后查看java.nio/BufferPool/dir ...

  2. JAVA使用堆外内存导致swap飙高

    https://github.com/nereuschen/blog/issues/29 堆内内存分析一般用Memory Analyzer Tool http://tivan.iteye.com/bl ...

  3. Java NIO 堆外内存与零拷贝

    一.直接缓存 这个例子的区别就是 ByteBuffer.allocateDirect(512); 进入allocateDirect方法 进入DirectByteBuffer构造函数 Native方法: ...

  4. Netty之Java堆外内存扫盲贴

    Java的堆外内存本来是高贵而神秘的东西,只在一些缓存方案的收费企业版里出现.但自从用了Netty,就变成了天天打交道的事情,毕竟堆外内存能减少IO时的内存复制,不需要堆内存Buffer拷贝一份到直接 ...

  5. Java堆外内存之三:堆外内存回收方法

    一.JVM内存的分配及垃圾回收 对于JVM的内存规则,应该是老生常谈的东西了,这里我就简单的说下: 新生代:一般来说新创建的对象都分配在这里. 年老代:经过几次垃圾回收,新生代的对象就会放在年老代里面 ...

  6. Java堆外内存之六:堆外内存溢出问题排查

    一.堆外内存组成 通常JVM的参数我们会配置 -Xms 堆初始内存 -Xmx 堆最大内存 -XX:+UseG1GC/CMS 垃圾回收器 -XX:+DisableExplicitGC 禁止显示GC -X ...

  7. cassandra 堆外内存管理

    为什么需要堆外内存呢 单有一些大内存对象的时候,JVM进行垃圾回收时需要收集所有的这些对象的内存也.增加了GC压力.因此需要使用堆外内存. java 分配堆外内存 org.apache.cassand ...

  8. JVM源码分析之堆外内存完全解读

    JVM源码分析之堆外内存完全解读   寒泉子 2016-01-15 17:26:16 浏览6837 评论0 阿里技术协会 摘要: 概述 广义的堆外内存 说到堆外内存,那大家肯定想到堆内内存,这也是我们 ...

  9. Netty堆外内存泄漏排查,这一篇全讲清楚了

    上篇文章介绍了Netty内存模型原理,由于Netty在使用不当会导致堆外内存泄漏,网上关于这方面的资料比较少,所以写下这篇文章,专门介绍排查Netty堆外内存相关的知识点,诊断工具,以及排查思路提供参 ...

随机推荐

  1. python jinjia2 使用语法

    简介 对于jinjia2来说,模板仅仅是文本文件,可以生成任何基于文本的文件格式,例如HTML.XML.CSV.LaTex 等等,以下是基础的模板内容: <!DOCTYPE html> & ...

  2. electron-vue打包出现问题汇总

    打包过程中出现下载status code 404 1.可能是网络不好,导致相关electron包无法正常下载,也有可能是需要挂代理 2.可能是编译过程的链接出现错误,一般为网址中缺少或多了一个v,建议 ...

  3. 困扰所有SAP顾问多年的问题终于解决了

    相信每个从事SAP的顾问都会遇到这样的场景:听着歌,录着SAP数据,写着ABAP代码,突然一切都消失了. 是的,SAP GUI又崩溃闪退了. 可能你还一脸懵逼不知道发生什么事情,当你重新登录系统的时候 ...

  4. Apache DolphinScheduler 使用文档(7/8):系统参数及自定义参数

    本文章经授权转载,原文链接: https://blog.csdn.net/MiaoSO/article/details/104770720 目录 7. 参数 7.1 系统参数 7.2 时间自定义参数 ...

  5. django的csrf跨站请求伪造

    1.什么是跨站请求伪造 请看图: 我们自行写了一个网站模仿中国银行,用户不知道是否是真的中国银行,并且提交了转账信息,生成一个form表单,向银行服务器发送转账请求,这个form表单和正规银行网站的f ...

  6. 开发H5程序或者小程序的时候,后端Web API项目在IISExpress调试中使用IP地址,便于开发调试

    在我们开发开发H5程序或者小程序的时候,有时候需要基于内置浏览器或者微信开发者工具进行测试,这个时候可以采用默认的localhost进行访问后端接口,一般来说没什么问题,如果我们需要通过USB基座方式 ...

  7. flutter系列之:用来管理复杂状态的State详解

    目录 简介 StatefuWidget和State State的生命周期 总结 简介 Flutter的基础是widget,根据是否需要跟用户进行交互,widget则可以分为StatelessWidge ...

  8. 快速搭建 SpringCloud Alibaba Nacos 配置中心!

    Spring Cloud Alibaba 是阿里巴巴提供的一站式微服务开发解决方案,目前已被 Spring Cloud 官方收录.而 Nacos 作为 Spring Cloud Alibaba 的核心 ...

  9. 游标长时间open导致表无法vacuum问题

    一.问题描述 用户在实际中可能会碰到类似以下 dead rows 无法 vacuum的问题,一个可能的原因是由于游标未结束的原因. test=# vacuum(verbose) t1; INFO: v ...

  10. Cluster table 与性能

    用户数据行存储在文件系统中的堆文件中,而这些行以不确定的顺序存储.如果表最初以插入/复制的顺序加载,那么以后的插入.更新和删除将导致在堆文件中以不可预测的顺序添加行.创建索引创建一个指向堆行的辅助文件 ...