Java的四大引用，大家都很熟悉吧： 强应用：正常代码中的引用。一个对象能通过强应用访问到，那它就永远不会被回收 软引用：比强引用弱一级的引用，内存不足时引用指向的对象会被回收 弱引用：比软引用弱一级的引用，下一次GC时指向对象会被回收 虚引用 最后一个虚应用是今天要讨论的。很多文章都是这么写的： 一个对象是否有虚引用存在，对其生存不会产生任何影响。 事实上，这个是错的。正确的表述是： 在

在从零开始使用Spring Cloud Config中，我们简单了解了下Spring Cloud Config，它提供了一套配置管理的解决方案。 但是Spring Cloud Config需要自己搭建config-server，还需要结合eureka来实现高可用；如果需要实时更新配置，还需要Spring Cloud Bus。实在是过于繁琐。 而阿里云ACM（应用配置管理）则提供了一整套完整的解决方

在传统的Java应用中，应用配置都是直接存储在代码库中（比如放在application.yml中)，配置的更新需要修改发布包并重新发布。 而配置的审计也会和代码夹杂，需要从众多提交中中找到配置变更的提交，很难独立完成，也很难追溯何时修改了某一项配置。 随着微服务的发展，服务越来越多、配置也越来越多，这种原始的配置管理方式，很难适应分布式环境。作为开发者，还是需要配置能单独地管理和审计。 Sprin

Java14近日发布，其中引入了新的record类型，虽然这是个预览特性，但是也不妨碍我们尝试下。 record类型record类型和普通的类相比，有几个特点 每个字段都是private final的，类本身是final的 类只有一个所有传递所有参数的构造函数 每个字段会自动会有一个get方法，但是方法名和字段名一致（没有get前缀） 可以给字段添加注解，支持FIELD、METHOD和PARAM

Java 14在2020年3月17号正式发布，不久AdoptOpenJDK也跟进发布了新版。 JEP 358: Helpful NullPointerExceptions其中对使用者比较有用的功能是 JEP 358: Helpful NullPointerExceptions，即在NullPointerException的message中指明为什么产生了这个NPE。 示例代码如下（需要Java14

公司内部发布maven包是在公司构建服务器上编译的。最近一次上线，发现同样的代码，在本地的jdk8上能编译通过，但是在构建服务器上，就编译报错。 简化后的代码如下： JavaBugTest.java12345678910111213import java.util.Optional;public class JavaBugTest { public static <T, E

先说结论知道大小的情况下，new HashMap的时候这么写： 1HashMap<Integer, String> map = Maps.newHashMapWithExpectedSize(expectedSize); 正文Java中的HashMap大家都很熟悉，其底层使用了Node数组来存储Map中的数据。但是如果存储的数据太多，空间不够，就需要扩容这个数组来存储新的数据了。 扩

昨天，线上OOM，dump下来hprof文件，里面有两个大数组： 从表象上来看，和thrift导致的oom是一样的： 但是问题是，这种情况是怎么出现的呢？ 找了好几种办法，没有头绪。 最后发现，把这个byte数组转成string就看到了thrift服务端的错误信息。 当时为了快速解决问题，是直接将前60个byte手抄到java代码中，然后转成string输出。 但是，不能一直都这么干，所以就看

最近线上有一个多线程的任务，会调用几个Thrift服务。 上线后观察到这个脚本在执行一段时间后，会有好几次Full GC，然后就会报OOM错误。 那就先下载heap dump（推荐压缩后，使用rz下载到本地），使用VisualVM分析。首先切换到Objects页面，看下是否有大对象： 可以看到，有两个byte数组占用了大量内存，也可以看到这个对象是在Java栈上的，接下来就是要找谁在使用这个变量

作为一个从PHP转Java的人，发现alibaba的arthas很好用。通过arthas的redefine命令，可以像PHP一样，不用重新发布，就可以改变程序行为（前提是不改变类结构，不改变方法签名）。 但是用多了，发现很多时候，我们就改了几行代码，甚至有的时候就添加了一行日志，就无法redefine了。提示 redefine error! java.lang.UnsupportedOperat