vim-quickfix窗口
vim quickfixvim 自带quickfix功能，很多插件也会利用这个窗口，把错误信息在这个窗口上显示。命令：
123456:help quickfix# 打开 quickfix:copen# 关闭 quickfix:cclose
效果：
vim-go quickfixvim-go 也是使用的 quickfix 输出，命令：
1GoLint
coc 调用需要依赖fzf，在普通模式下执行：
按住 空格不放 + a，调用
总结quickfix窗口，是个很实用的vim内置工具，开发过程中很常用，自带的quickfix窗口其实功能还是有点欠缺，最好是加上一些相关插件，用起来更舒服。
shell 删除目录下备份目录数量
前言经常需要通过脚本来控制系统目录的里备份文件数量。不可能手动来经常查看，总是忘记。通过脚本定期自己查看目录里的文件数据，删除时间较早的目录。
实现那么就要设置几个条件：
允许存在几个目录
超过了怎么删除
怎么判断目录下有多少个目录？用ls就可以。
那多出来的怎么删除？遍历删，直到没有为止
完整代码如下：
1234567891011#!/bin/bashdirCount=5# 查看当前目录数currentDirCount=`ls -l | grep "^d" | wc -l`# 遍历删，直到没有为止while [ $currentDirCount -gt $dirCount ]do rm -rf `ls -1|head -n 1` currentDirCount=`ls -l | grep "^d" | wc -l`done
过滤目录，d 表示目录
grep "^d"
制造一些测试数据，然后执行上面的脚本验证。
1mkdir test1 test2 test3
最后一个问题，什么时候来执行呢？这个就看具体的策略 ...
新生代收集器 Parallel Scavenge
新生代，多线程，使用复制算法，是多线程的并行的收集器。目标：达到一个可控的**吞吐量(Throughput)**。吞吐量：CPU用于运行代码时间 与 CPU总消耗时间的 比公式： 吞吐量 = 运行代码时间 / ( 运行代码时间 + GC时间）虚拟机运行 100 分钟，GC用掉1分钟，则吞吐量为99%。 100 /(100 + 1) = 0.99
停顿时间越短越好-XX:MaxGCPauseMillis： 最大GC停顿时间，最小可为0-XX:GCTimeRatio: 吞吐量大小,1-100
停顿时间与空间成反比停顿时间越短，则新生代的空间就越小。通过减小新生代的空间，让里面的垃圾变少，从而加快了集速度。原来：500MB 垃圾，10秒收集一次，每次停顿100毫秒为了缩短时间，修改** -XX:MaxGCPauseMillis** 参数，使新生代空间变小，产生的垃圾就少了，停顿时间短了：现在：300MB 垃圾，5秒收集一次， 每次停顿70毫秒。
那时问题来了，停顿时间下降了，但是频率高了，则吞吐量也跟着降下来了。
GC 时间占总时间的比例GCTimeRatio 进行这个设置1-100 ...
git 取消跟踪
取消跟踪未提交文件忽略
git rm --cached FILENAME
这样就可以了，如果后面跟的是目录就加上个 -r 就行了（这个操作不会删除这个文件）
git rm -r --cached DIR
已提交文件忽略已经维护起来的文件即已经 commit 后的文件，即使加上了.gitignore也无济于事。用下面这个命令：
git update-index --assume-unchanged logs/*.log
git制造冲突
冲突来源于合并不同分支的 commit 是不会产生冲突的，因为 commit 提交到的是当前分支的 本地库。只有将分不同分支的本地库进行合并才会产生冲突。所以：
合并本地库会产生冲突
拉远程分支的代码也会产生冲突
通常产生的情况：
两个人写同一个文件就可以先提交的不会有冲突，后拉取的会有冲突
同一个机器，不同分支，写同一个文件，也可以产生冲突
制造方法：A 、B 两分支操作同一个文件的同一行代码。A 分支 commitB 分支 commit
B 合并 A，就会产生冲突
什么是线程安全?举例说明，区别。
线程安全:当多个线程访问某个方法时，不管你通过怎样的调用方式或者说这些线程如何交替的执行，我们在主程序中不需要去做任何的同步，这个类的结果行为都是我们设想的正确行为，那么我们就可以说这个类时线程安全的。
线程不安全:在多核CPU的环境下，当多个线程访问同一个共享变量时，这个变量没有使用任务同步机制，会出现CPU 缓存同步内存不及时，导致出现数据不同步的情况，这就是所谓的线程不安全。单核CPU没有这个问题。
hashcode用在哪
hashCode的存在主要是用于查找的快捷性，如Hashtable，HashMap等，hashCode是用来在散列存储结构中确定对象的存储地址的；如果两个对象相同，就是适用于equals方法进行比较，那么这两个对象的hashCode一定要相同；
hashcode 相等两个类一定相等吗? equals呢? 相反呢?
结论:不一定相等。
原因:hashCode 算法有一定概率产生相同的 hashCode，即 hash 碰撞。
分重写 和 未重写 hashcode、equals 方法两种场景：
一、hashcode 方法 和 equals 方法没有重写时
hashcode相等两个类不一定相等
equals返回true的两个类一定相等（为同一个对象）
两个类相等hashcode不一定相等
两个类相等equals不一定返回true
二、hashcode 方法和 equals 方法均已按规范重写时
hashcode相等，两个类不一定相等（存在哈希冲突）
equals返回true的两个类一定相等
两个类相等hashcode一定相等
两个类相等equals一定返回true
java 解决JDK内置工具不能使用问题
问题在服务器上准备排查服务进程问题，想使用jstat和jcmd这些工具，然后发现给我报了个错：
bash: jstat: command not found
这是什么鬼，程序正常跑着，难道JDK还有阉割版？看看版本，这个很正常。
123java version "1.8.0_291"Java(TM) SE Runtime Environment (build 1.8.0_291-b10)Java HotSpot(TM) 64-Bit Server VM (build 25.291-b10, mixed mode)
那去看看bin下面是不是把这些工具全删了：
1echo $JAVA_HOME
结果没有 JAVA_HOME 路径，这难道又是从/usr/bin指过去的，怎么总是喜欢这么玩。
1which java
结果，还真的是
/bin/java
那再看看这个java是指向哪里的：执行命令
1ll /bin/java
显示路径是：
/bin/java -> /etc/alternatives/java
那么也就是指向了 /etc/alterna ...
java exception和error异常和错误
体系我们在使用java的时，经常面对和处理的是异常(Exception)很少处理错误。因为如果是错误级别的往往都是比较底层的非代码层面的问题。但是这两个的区别，有必搞清楚。这两个是一对难兄难弟，有问题的时候都会出现这两兄弟。
通过图片可以直观的看出它们的体系，这图点开看比较清楚：
异常 Exception这个是最常遇见的问题，主要是由于编码原因异常的问题。我们开发过程中常见的是运行时异常，就是字面意思，运行时才知道的异常，运行时，才会有可能抛出来的异常。那相对的，就有非运行时的异常，就是不需要运行，也能知道是异常。
而异常当中，又有几个概念，这些概念性的东西，只是帮助分类和理解，使用场景可以说是经常遇见，分别是：
两种异常：
运行时异常 RuntimeException
异常 Exception
运行时异常 RuntimeException只有运行时才会知道是否有异常，比如下面这段代码会不会抛常异？
123456public class Test { public void test(int a, int b) { int c = a / b; &# ...
