jvm
netstat -anlp | grep 3306 查询指定端口使用情况
sudo netstat -ap 查看所有的服务端口占用情况
通过进程id查看占用的端口 netstat -nap | grep 进程id
通过端口号查看占用的进程id netstat -nap | grep 端口号
ps aux | sort -k4,4nr | head -n 10 查看内存占用前10名的程序
jconsole:
-Djava.rmi.server.hostname=10.31.25.226
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=36554
-Dcom.sun.management.jmxremote.rmi.port=36517
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false evo-download.jar
java -jar -Xms256m -Xmx768m -Xss256k -XX:NewSize=64m -XX:MaxNewSize=384m -XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=128m -Djava.rmi.server.hostname=10.35.225.187 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=37164 -Dcom.sun.management.jmxremote.rmi.port=26154 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false evo-download.jar
CMS:
java -jar -Xmx512m -Xss256k
-XX:NewSize=64m -XX:MaxNewSize=170m
-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=128m
-XX:-UseConcMarkSweepGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=70
-XX:+CMSParallelRemarkEnabled
-Djava.rmi.server.hostname=10.31.23.200 -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=29866 -Dcom.sun.management.jmxremote.rmi.port=29831
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
evo-download.jar
-Dcom.sun.management.jmxremote 添加远程连接 用于 jConsole等java监控工具
2. -XX:CMSInitiatingOccupancyFraction=70 和-XX:+UseCMSInitiatingOccupancyOnly
这两个设置一般配合使用,一般用于『降低CMS GC频率或者增加频率、减少GC时长』的需求
-XX:CMSInitiatingOccupancyFraction=70 是指设定CMS在对内存占用率达到70%的时候开始GC(因为CMS会有浮动垃圾,所以一般都较早启动GC);
-XX:+UseCMSInitiatingOccupancyOnly 只是用设f定的回收阈值(上面指定的70%),如果不指定,JVM仅在第一次使用设定值,后续则自动调整.
3. -XX:+CMSScavengeBeforeRemark
在CMS GC前启动一次ygc，目的在于减少old gen对ygc gen的引用，降低remark时的开销-----一般CMS的GC耗时 80%都在remark阶段
UseCMSCompactAtFullCollection 与 CMSFullGCsBeforeCompaction
独享锁是指该锁一次只能被一个线程所持有。 (ReentrantLock、 Synchronized)
这两种方式最大区别就是对于Synchronized来说，它是java语言的关键字，是原生语法层面的互斥，需要jvm实现。
而ReentrantLock它是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成
便利性：很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。
锁的细粒度和灵活度：很明显ReenTrantLock优于Synchronized
springboot IOC容器 对象初始化 懒加载
Java单例模式（饿汉式，懒汉式）
redis 淘汰机制
