coc-java无法启动和lombok报错解决
问题一问时间不写java,这两天写java程序发现vim-java相关配置失效了,症状就是:
语法提示服务jdt不启动
lombok 失效
排查了一圈发现启动后官方的插件配置名都变了,改用合结vs-code的配置,又折腾了好一会。
解决更新jdt从官方jdt下载一个新包:https://github.com/eclipse/eclipse.jdt.ls备分:~/.config/coc/extensions/coc-java-data/server/ 目录,把下载的新包,内容放到 server下。
解决 lombok 报错问题还没完,启动后发现lombok报错,首先coc-java-lombok必须安装,没装的可以装一下
1CocInstall coc-java-lombok
然后安装OpenJDK,这个已验证必须使用OpenJDK才能解决这个问题。最后清理一下项目,很多人发现改完也没有效果,就是因为没有清理:
1CocCommand java.clean.workspace
java 服务大量外部连接导至异常
相信很多小伙伴都碰到过一个问题,服务运行过程中,产生大量的未关闭的TCP链接,导至服务不可用直至服务异常。该如何定位、排查这些未关闭的链接?之前碰到过这个问题,解决了,今天有小伙伴又聊到这个问题,就将这个问题复现出来,如果有人看到这个问题,可以帮助解决这个问题。
复现通过 jmeter 复制问题,由于问题已经被解决,但是可以通过 jmeter 100%复现该问题。
复现流程:
通过 jmeter 发起 http 请求,并且不释放请求。
停止 jmeter 后查看状态
java.net.NoRouteToHostException: Can't assign requested address (Address not available) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
报的错是Can't assign requeste ...
jvm 使用CMS时FGC每次会跳2次
现象使用jstat -gc观察CMS FullGC的时候,发现每次到阈值回收的时候,FGC每次会跳2次:
123456789101112 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT68096.0 68096.0 0.0 16853.2 545344.0 371165.3 8755648.0 5890791.6 62312.0 59746.5 7076.0 6608.5 43879 1312.752 60 5.206 1317.95868096.0 68096.0 19377.9 0.0 545344.0 420827.3 8755648.0 5891528.9 62312.0 59746.5 7076.0 6608.5 43880 1312.785 60 5.206 1317.99168096.0 68096.0 0.0 ...
CMS回收器执行流程
CMS(Concurrent Mark Sweep)目标:获取最短回收停顿时间为目标的收集器。算法:"标记-清除"算法实现
CMS是老年代垃圾收集器,在收集过程中可以与用户线程并发操作。它可以与 Serial 收集器 和 Parallel New收集器搭配使用。CMS牺牲了系统的吞吐量来追求收集速度,适合追求垃圾收集速度的服务器上。可以通过JVM启动参数,来开启CMS:
-XX:+UseConcMarkSweepGC
牺牲吞吐量,追求收集速度是什么意思
其实实际使用过程中发现,CMS是将每次收集的时间减少,但是垃圾还是那么多,于是回收的工作方式就变成了跟吃自助餐常听到的一样"勤拿少取",就是每次回收时间短,也并不完全回收全部的垃圾,通过多次回来处理。
1.初始标记(CMS initial mark)单线程,标记新生代可达老年代的对象。为了收集应用程序的对象引用需要暂停应用程序线程,该阶段完成后,应用程序线程再次启动。
2.并发标记(CMS-concurrent-mark)在第一个阶段(Initial Mark)被暂停的应用线程将恢复运行 ...
spring 源码01 开始阅读
在开始源码阅读之前,一定要使用过这个产品,了解这个产品的功能、特点。
在开始源码阅读之前,需要先明白几个事
是否足够了解
要阅读到什么程序
如何开始、从哪里开始
开始前最好是带着问题去阅读源码,不纠结于小细节。我一般读源码就是碰到问题后,带着问题去看,效果更好,不要想着假大空,把源码当小说一样看。单个问题解决后,再向外延伸,就可以把一些点串起来。最后,需要反复看一些重点部份,消失对源码的陌生感之后就会能看进去。熟悉之后就会一种想要了解更多的感觉就会一直往下看,这个就是自动驱动的动力。
如果看不下去,不要责怪自己懒,人对看不见短期收益的事提不起兴趣这才是正常的一个人,趋利避害是正常的。看不下去,该干嘛干,强迫自己看效果很差。不要骗自己,假装努力是在浪费时间,干IT的都很忙,看不去就看改改bug。
技巧
对说某个功能,在看之前,可以有自己的推测,想像后续的流程是如何执行的。
切一个 read_code 分支用来作注释,写上自己的见解,也方便以后再回到这块代码时能快速理解。
找到真实阅读源码的动力,如:
准备跳槽、面试
想了解原理
解决项目中的问题
装逼
跑测试用例,好的开源软件 ...
shutdownHook 死锁解决
最近碰到一个问题,通过脚本执行kill -15后,程序并没有退出,进程一直都在,最后被退出脚本的通过kill -9,杀死。导致数据完整性被破坏,程序再重启后不可用。通过排查认后发现是在执行shutdownHook时死锁程序死锁。
复现问题导致问题的代码,通过定位发现,程序在退出时卡住,线上代码敏感,写一个demo来复现:
12345678910111213141516171819public class Test { private static final Object lock = new Object(); public static void main(String... args) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { System.out.println("Locking"); synchronized ...
idea 2021 Debug卡住一直提示Collecting data
还是IDEA 的问题 mac M1 加 IDEA2021的问题还真不少,debug时发现会一直卡住,在调用底层jar包时,创建一个对象就一直提示 Collecting data,并没有断点。
解决
把 Enable toString() 去掉即可解决。
另外,彻底解决卡顿问题,还是要换 zulu JDK和IDEA(ideaIU-2021.2.2-aarch64.dmg),这样一套搞下来就不卡了。
Zulu JDKhttps://www.azul.com/downloads/?package=jdk
spring 源码阅读环境
要进行源码阅读之前,强调需要先对一个产品有熟悉的使用,就好像你想要造车,要先会开车,再去学习如何造车,否则一切都是停在理轮上,完全不了解这个车是如何运行的,没有概念。推荐对需要阅读的源码先保存在自己仓库中,并创建一个源码分支,可以在阅读分析的过程中对重要点进行注释帮助加深理解。
fork源码Spring 官方github源码仓库
https://github.com/spring-projects/spring-framework
构建源码阅读环境将代码 clone 到本地,克隆完成后,IDEA自动打开项目。
报错处理,首次打开会报个错,别慌这是因为IDEA缺少必要插件,点右侧 gradle 的构建按钮构建一次。
首次构建需要下载的包比较多,
直接使用 git clone 方式直接使用命令行git clone 项目的话,拉完代码后,IDEA 通过导入的方式导入项目。
file--->new--->Project from Exisitings Sources
后续步骤相同。
gradle 问题spring 是基于gradle进行构建的,如果没有安装gradle也没 ...
gradle 安装
安装官网
https://gradle.org/
下载页面https://gradle.org/releases/
选择自己需要的版本,下载已经编译好的二进制文件Download: binary-only
设置环境变量设置 .bash_profile 文件添加
export PATH=$PATH:/Users/liukai/workspaces/application/gradle-6.6.1/bin
验证一下
IDEA2021使用tomcat启动时间超长
最近换了 mac M1 加 IDEA2021 后,发现问题还真不少,先是解决了卡顿问题后,tomcat 启动时间从原来的十几秒,变成20分钟!!!超不正常。
新电脑问题多。
直接说怎么解决的。
解决
scutil --set HostName "localhost"
无效的偿试-修改生成随机数IDEA2021 添加tomcat启动参数,JRE默认使用 /dev/random作为随机数来源,当熵池大小不够的时候,random会很慢,造成随机数生成调用阻塞。
JAVA_OPTS="-Djava.security.egd=file:/dev/urandom"无效,依然该怎么慢还怎么慢。
真正原因 Jvm需要很长时间解析localhost的IP地址原因分析https://www.codenong.com/39636792/