kkgbn的博客

原文地址点击打开链接社区内有人发起了一个讨论，关于JVM是否一定需要GC？他们认为应用程序的回收目标是构建一个仅用来处理内存分配，而不执行任何真正的内存回收操作的 GC。即仅当可用的 Java 堆耗尽的时候，才进行顺序的 JVM 停顿操作。首先需要理解为什么需要GC。随着应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行。而经常造成STW的G

①首先说一下，GC里边在JVM当中是使用的ROOT算法，ROOT算法，什么称作为ROOT呢，就是说类的静态成员，静态成员就是static修饰的那种，是“根”的一个，根还包括方法中的成员变量，只有成员或对象不挂在根上，GC的时候就可能把他们搞掉，这里提到的循环引用，就看这个循环引用是否挂在根上，如果挂在根上，如果这个根还被JVM的Java代码所执行的话，就不会GC掉，如果说这个根已经被释放掉了，这个

CASCAS,自旋锁跟compare and set有关系,但是并不是CAS就是自旋锁。我们看一段代码：/* 不同线程检测最大值 */ AtomicLong largest = new AtomicLong(); long obsvValue = 0; /* 错误的方式,此更新不是原子性的 */ largest.set(Math.max

volatile的语义volatile 的语义是memory barrier可以参考一下Java 内存模型。线程在启动后，读取内存Heap 值复制到自己的工作缓存，比如寄存器、N级缓存等。寄存器、N级缓存在CPU，如果需要其他线程感知的话，需要同步是主存中，如果其他线程看到变量是volatile的话，回去主存加载。Heap 就存放在主存中，也就是内存中。volatile 实际上是强制线程去主存中读取

晚上忽然发现自己的MAC从运行程序到看到Spring boot日志时间超过20秒。新建个空的boot空工程也需要10秒才会看到boot的启动日志。 最后设置了gc日志看了下有无异常情况。 从jvisualvm看下 Java HotSpot(TM) 64-Bit Server VM (25.131-b11) for bsd-amd64 JRE (1.8.0_131-b11), built o

jstacklocalhost:jvm_test_dump bao$ jstack 574262017-07-07 10:58:50Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode):"JMX server connection timeout 14" #14 daemon prio=9 os_pr

1. Java8public class TestGetMethodParamName { public String test(String name, Integer age) { return null; } public static String printMethods() { StringBuilder sb = new Strin

4款Java垃圾回收器——错误的选择导致糟糕的性能对大多数开发人员而言有两件事情是个谜——垃圾回收以及异性。由于我对后者也不是特别了解，我想我还是试着说说前者吧，尤其是随着Java 8的到来，这个领域也发生了许多重大的变化及提升，其中最重要的莫过于持久代（PermGen）的删除以及一些令人振奋的新的优化（后面会陆续提及这些）。说起垃圾回收，许多人都了解它的概念，也在日常的编程中有所

1.简单介绍在ThreadLocal类中有一个Map，用于存储每一个线程的变量副本，Map中元素的键为线程对象，而值对应线程的变量副本。 下面是示例：public class ThreadLocalTest { /*1通过匿名内部类覆盖ThreadLocal的initialValue()方法，指定初始值 */ private static ThreadLocal<Integer>