xialonghua的专栏

最近发现个问题有个aliyun的oss sdk版本指定了不起作用，一直是很老的版本。依赖树打印也是没有问题的。最后临时取巧强制指定版本解决。配置到parent pom里即可<dependencyManagement> <dependencies> <dependency> <groupId>com.aliyun.oss</groupId> <artifactId>aliyun-sdk-

背景项目上线后，发现过段时间就会请求失败OOM。经过排除，哪怕请求一个空的接口都会OOM，请求分配内存失败。原因最后发现有次配置文件上传，从网上复制了一个配置maxHttpHeaderSize设了100M。经过查看源码，是因为请求来了后，会先创建Http的Processor，然后将这个Processor缓存起来复用。Processor会直接根据maxHttpHeaderSize来申请http的inputBuffer和outputbuffer。那么就导致了创建了几个Processor后内存就直接满

背景搭了一个初始工程，使用的是spring boot 2.2.6。结果发现LocalDateTime返回到前端后变成了数组。网上找了遍都是不知道哪抄的，没一个行的。问题根源还是通过查看源码的方式，发现默认序列化情况下会使用kotlin SerializationFeature.WRITE_DATES_AS_TIMESTAMPS。所以打印出数组。 @Override public void serialize(LocalDateTime value, JsonGenerator g, Ser

背景这是个大坑，记录下。项目接入了tinker做热修复，可是呢一行代码不改，你猜补丁多大？10M加固后生成的补丁，你猜多大？18M这简直是不能接受啊！结论先说结论，因为其他都是废话，也没人关心，希望结论能帮助到他人。matrix导致tinker补丁过大项目里用例tinker+matrix，这俩是微信一家的matrix在做方法耗时插桩时，会在代码里每个方法里插入开始和结束...

import hudson.model.* def q = Jenkins.instance.queue println(Jenkins.instance.pluginManager.plugins)q.items.findAll { it.task.name.startsWith("jenkins job 名字") }.each { packageId="" ...

背景服务器上线后，莫名其妙收到CPU高的报警。那么该如何排查呢？方法jps命令查看java对应的进程IDtop -H -p PID 查看当前进程中线程状态，找到比较占CPU的几个PIDprintf “%x\n” PID 线程ID转换成16进制jstack 31057|grep 16进制PID -A 30 查看对应线程状态信息根据返回可看到是执行到哪里导致CPU过高...

背景这次项目做完，用公司发布系统编译的时候，报错了。因为是混编，结果报kotlin文件都找不到。maven clean package -U这是打包命令，可是因为是发布系统模板所以不好改命令。解决方案可以改编译命令的前提下这个不多说了，网上挺多人复制的。其实就是在package前面强制先编译kotlin。三方链接不修改打包命令的前提下这个就不好搞了。最后还是在kotlin官网找到了答...

前言有时候看别人的代码，虽然执行结果一样，但是会发现自己的代码写的跟屎一样。那么有哪些方法可以让我们自己也写出比较优雅通俗易懂的代码呢？任何代码都是人一行行码出来的，因此还是要提高自己的水平来输出优秀的代码。我们从以下几个方面来提高自己：命名规范适当的注释消灭重复超大的函数if-else简化设计模式命名规范好的命名规范是写好代码的第一步，命名别人都看不懂，最后自己都看不懂...

写了个springboot项目。本想图个吉利端口号起做6666。结果Chrome报了这个错。最后发现是因为6666为Chrome的黑名单里。下面是端口列表,换个端口即可：6666-6669这几个端口是IRC协议使用的缺省端口，存在很大的安全风险，很容易被木马程序利用，出于安全方面chrome禁止了对6666端口的访问，同样使用webkit内核的chrome缺省状态下也是禁止访问这几个端口的。...