在传统的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

题意每层括号里面的东西需要反转一次。即在在偶数层括号里面的字符是正序的，在奇数层括号里面的字符是逆序的。然后拼成结果。 例子： “(abcd)”反转之后就是：dcba “(u(love)i)”love不反转，u,love,i三个反转，答案为：iloveu 思路网上有人直接用栈存储，每一个元素代表当前层级括号中的字符串，如果遇到括号关闭，将当前层级字符串反转再append到上一级的字符串中。 但是，

最近，fastjson又爆出一个漏洞，在解析特殊字符的时候，直接OOM： 首先分析一下整体流程： 在scanString时，会直接读取两个字符： 而在next方法中，每次读取都会将bp的值加一（即使没有从输入中读取字符）： 123456public final char next() { int index = ++bp; return ch = (index >=