引言
编写目的
目前线上问题是以java的为主，但是配置方式不是特别的统一，把这些进行统一化后有利于问题的定位和解决一些不稳定因素。
阅读对象
开发人员、运维人员。
JAVA项目线上配置
启动java应用注意事项
服务器一定要安装JDK，不要JDK和JRE混装，要使用JDK作为系统环境变量，并且使用JDK启动java服务，否则jps,jmap,jstat等工具不能使用。如果不能使用将不能对java的进程进行监控和排错。
JDK版本
建议使用较为稳定的以及市面上较多使用的JDK版本。目前是 1.7和1.8版本使用较为广泛，不建议使用过低或者过高的版本。Jdk1.7 官方以及不在出新的update，已经属于较老的版本，但是目前还是使用的比较广泛Jdk1.8官方推荐的版本，目前还在不断更新，并且较之前的版本有较大的改进，目前比较流行，可以使用。
操作系统选择
JAVA是夸平台的，但是在Linux的运行效率要高于window系统，所以，如果没有特别的依赖，建议使用Linux系统，可以使用云服务提供的Liunx镜像，例如Ubuntu的或者Centos的。 JAVA服务通用配置 Java的内容配置需根据操作系统内存做调整，主要调整的是 Xms Xms PermSize MaxPermSize，垃圾回收，gc信息等。下表是一个大概说明：
| 属性 | 值 | 说明 |
|---|---|---|
| Xms | 2048M 或 4096M | 设置JVM最大可用内存，建议根据机器配置设置最大2G或者最大4G,例如机器16G内存，那服务的最大可用内存可以设置为4G |
| Xmx | 2048M 或 4096M | 设置JVM初始内存大小，大访问量的Xmx和Xms设置大小建议一样，这样在系统运行的时候就不需要在每次都扩张Xmx内存了，小服务可以设置的低一些，刚开始会减小内存占用。 |
| Xmn | 建议不加此参数让jvm自动分配如果要手工分配一定要参考Xmx和Xms的大小 | 设置年轻带大小，正常来说年轻带就是在不断的GC的，年轻代设置不合理可能会减少年老代的大小，所以这个建议不是特别调优的可以使用默认值 |
| Xss | 128K | 设置每个线程的堆栈大小.JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行 调整.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右 |
| XX:PermSize(请注意jdk1.7和之前的jdk才有此设置jdk1.8使用新的设置) | 256M或512M | JDK1.7包括以前的永久代设置，永久代只有在fullgc的时候回收，缓存了很多不会改变的内存元素，所以尽量不要太小，建议根据整体内存配置为256M或者512M，如果整体内存4G就设定512M如果小就256M，这个设置包含在Xmx中。 |
| XX:MaxPermSize(请注意jdk1.7和之前的jdk才有此设置jdk1.8使用新的设置) | 256M或512M | 永久代最大值，建议和初始值设为一样，这样不要动态扩展带来的效率浪费 |
| -XX:MetaspaceSize | 256M或512M | Jdk1.8以上版本改为元空间，屏蔽了永久代，把一些永久代的存储移动到了堆内存，这个和永久代规则建议保持一致 |
| -XX:MaxMetaspaceSize | 256M或512M | 建议设定值和MetaspaceSize一致。 |
| -XX:NewRatio | 4 | 新生代(Eden + 2*S)与老年代(不包括永久区)的比值 4 表示新生代 ：老年代 = 1：4 ，意思是老年代占 4/5 |
| -XX:SurvivorRatio | 8 | 2个Survivor区和Eden区的比值 8 表示 两个Survivor ： Eden = 2： 8 ，每个Survivor占 1/10 |
| -XX:+UseParallelGC | 选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。(适用于大对象高吞吐的收集器) | |
| -XX:+UseParallelOldGC | 配置年老代垃圾收集方式为并行收集。JDK6.0以上支持对年老代并行收集(适用于大对象高吞吐的收集器) | |
| -XX:ParallelGCThreads | 4 | 配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。 |
| -XX:+UseAdaptiveSizePolicy | 设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。(这个配置和上边的某些配置是冲突的用一个就行) | |
| -XX:+HeapDumpOnOutOfMemoryError | JVM 就会在发生内存泄露时抓拍下当时的内存状态，也就是我们想要的堆转储文件 | |
| -XX:HeapDumpPath | /var/log/heapdump.hprof | 堆转储文件路径 |
- 堆设置
-Xms:初始堆大小
-Xmx:最大堆大小
-XX:NewSize=n:设置年轻代大小
-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
-XX:MaxPermSize=n:设置持久代大小- 收集器设置
-XX:+UseSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParalledlOldGC:设置并行年老代收集器
-XX:+UseConcMarkSweepGC:设置并发收集器- 垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename- 并行收集器设置
-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)- 并发收集器设置
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。以下给出通用配置：
- 响应时间优先的并发收集器 JDK7配置：
Java -Xmx3550m -Xms3550m -Xss128k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdump.hprofJDK8配置：
Java -Xmx3550m -Xms3550m -Xss128k -XX:MetaspaceSize=256m -XX: MaxMetaspaceSize=256m -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdump.hprof吞吐量优先的并行收集器 JDK7配置：
java -Xmx3550m -Xms3550m -Xss128k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParallelGC -XX:ParallelGCThreads=8 -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdump.hprofJDK8配置：
java -Xmx3550m -Xms3550m -Xss128k -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -XX:+UseParallelGC -XX:ParallelGCThreads=8 -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdump.hprof*+请注意公司大部分业务都属于(响应时间优先+* ) 其他值建议在不是特别的理解的时候不要加上参数，比如新生代、年老代占比这类的。如果不是root账号启动的，一定要注意HeapDumpPath是有权限写入磁盘的。
Linux服务器配置
- 优化Liunx文件描述符(打开文件最大数)
Linux限制了任何进程可以打开的文件描述符数量，默认限制是每进程1024，这些限制可能会阻碍基准测试客户端(如httperf和apachebench)和Web服务器本身获得最佳性能，Apache每个连接使用一个进程，因此不会受到影响，但单进程Web服务器，如Zeus是每连接使用一个文件描述符，因此很容易受默认限制的影响。 打开文件限制是一个可以用ulimit命令调整的限制，ulimit -aS命令显示当前的限制，ulimit -aH命令显示硬限制(在未调整/proc中的内核参数前，你不能增加限制)。 Linux第三方应用程序性能技巧 对于运行在Linux上的第三方应用程序，一样有许多性能优化技巧，这些技巧可以帮助你提高Linux服务器的性能，降低运行成本。
- Tomcat日志配置
在window系统中tomcat日志默认没有catalina.out日志，记得配置，否则一些tomcat应用本身报错的日志可能没有被记录下来，只在控制台显示了。
Tomcat最好配置上访问日志与catalina.out日志。 Tomcat启动卡好几分钟
存在于部分版本的Linux服务器上，各种版本的tomcat都可能出现这个现象，因为这个现象的原因在某些版本的服务器上以及jdk上。 新部署的项目启动tomcat后一直停在
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine:
Apache Tomcat/8.5.16，卡在了org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/opt/tomcat/webapps/host-manager]
将近7分钟。
[root@app-web-2-64-0002 bin]# tail -500f ../logs/catalina.2018-07-04.out
......
04-Jul-2018 16:28:59.520 INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 328 ms
04-Jul-2018 16:28:59.534 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
04-Jul-2018 16:28:59.534 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/8.5.16
......
卡了近7分钟
......
04-Jul-2018 16:35:00.238 WARNING [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [360,548] milliseconds.
04-Jul-2018 16:35:00.273 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/opt/tomcat/webapps/host-manager]
....解决方法： 修改jdk的java.security文件securerandom.source项
[root@app-web-2-64-0002 bin]# grep "source=file" /usr/java/jdk1.8.0_161/jre/lib/security/java.security
#securerandom.source=file:/dev/random
securerandom.source=file:/dev/./urandom
[root@app-web-2-64-0002 bin]#
将securerandom.source=file:/dev/random修改为securerandom.source=file:/dev/./urandomlinux或者部分unix系统提供随机数设备是/dev/random 和/dev/urandom ，两个有区别，urandom安全性没有random高，但random需要时间间隔生成随机数。jdk默认调用random。可通过 head -n 1 /devrandom 查看是否的系统会出现伪随机数提供等待
JAVA项目线上监控
内存堆溢出(OOM)
发生OOM问题一般服务都会crash，业务日志会有OutOfMemoryError。OOM一般都是出现了内存泄露，需要查看OOM时候的jvm堆的快照，如果配置了-XX:+HeapDumpOnOutOfMemoryError, 在发生OOM的时候会在-XX:HeapDumpPath生成堆的dump文件，结合MAT，可以对dump文件进行分析。
注： 1、服务器的内存一般较大，所以要保证服务器的磁盘空间大于内存大小 2、另外手动dump堆快照，可以使用命令jmap -dump:format=b,file=file_name pid 或者kill -3 pid
死锁
死锁原因是两个或者多个线程相互等待资源，现象一般是出现线程hung住，更严重会出现线程数暴涨，系统出现api alive报警等。查看死锁最好的方法就是分析当时的线程栈。
具体case 可以参考jstack命令里面的例子用到的命令：
jps -v
jstack -l pid找到哪个线程占CPU时间大
这里用一个公司的实际例子来说明，在2019-03-29包括之前大家说的，REP服务基本上启动后不久就达到了CPU占用90%以上，其实没什么压力的情况下，我意识到这是个不正常现象，然后就要了一个服务器上去进行问题查看，以下记录这个过程。
使用命令
jps –v查出结果
使用命令
ps –Af查出这个进程使用 www 用户启动。 这时候需要切换到www用户 并使用jstack命令，否则会出现无法连接。
su www使用命令：
top –Hp 75466 (75466在jps中是java项目的进程ID)可以看出75466 下边的线程id是77665的线程占用cpu时间达到了90%以上。 77665是十进制数转换为16进制是12f61. 打出命令 jstack 75466 (75466在jps中是java项目的进程ID)
打印出所有当前线程的信息以及线程的栈信息。可以把所有的copy出来到文本编辑器上。 查询文本中77665(线程id)是十进制数转换为16进制是12f61，得出结果：
可以看到出问题的线程不是自己写的程序，而是dubbo缓存zk配置文件的线程占用了90%以上的cpu。 这时候去百度箭头标出的一行可以看到，是有多个zk造成了dubbo服务会把多个zk缓存，但是缓存有锁，造成了保存线程卡死。 解决方法暂定为，所有服务都应该连接zk服务集群，而不应该连接多个zk，先修改代码避免此问题。
找到哪个线程占CPU时间大(window系统)
Window系统没有top命令，所以查线程的CPU时间需要使用第三方工具来实现。推荐使用的第三方工具是Process Explorer。如下图：
TID就是线程ID，这样就获取了线程ID，这样就可以和3.3的一致在下边使用换算方式，在使用jstack命令就可以查看是哪个线程出的问题以及线程的堆栈信息。 Jstack命令不好用，这个命令是在linux没有图形界面的时候才使用的，图形化的方式在window下是非常方便的，在这推荐使用jdk自带的jvisualvm和jconsole管理工具，在这里先介绍jvisualvm，在jdk的bin目录下找到这个exe文件，打开并选择自己java的进程，这个工具主要是监控，在线程部分可以实时监测线程状态活动线程，还有其他的监控项，在这只说线程部分。如下图右上红色矩形区域框起来的按钮，点击后得出的信息就是和jstack得出的信息是一样的。
在上面已经说明怎么把线程id转为16进制查询，在这里就不重复描述。 在抽样器的部分也可以看到线程名称占用的CPU时间长短，但是只能显示名称不能看到ID，所以，可以看到名称后，在通过线程名称找到这个线程的栈信息也是可以的，如下图：
这个工具的抽样器部分也可以看到哪个线程的内存占用比，占用内存过大的线程可能也有较大问题。如下图：
Jvisualvm是非常方便的，另外一个jconsole是不是也可以呢？jconsole并不智能，但是也可以看到栈信息，并且有一个检测死锁的按钮可以使用，但是看不出线程占用CPU以及线程ID，这个工具用来监视其他属性也许还行，但是检测线程是弱的，但是也可以根据名称看，如下图：
Jconsole的vm概要还是不错的，如下图：
Window图形化监控
3.3和3.4比起来在window系统中的监控方式比linux系统的命令行方式智能很多。Window的监控工具是否可以监视linux系统的进程呢？答案是肯定的，这个就变为远程监控形式了，远程监控就是在服务器上配置JMX的参数就行，把参数端口，密码设定好后，window的监控工具就可以远程监控JVM进程了，这样就很方便的可以同时监控N多个服务，但是请注意，一定要在远程的java启动参数上配置，并且需要重新启动服务。
线程block
jstack -l pid |wc -l
jstack -l pid |grep "BLOCKED"|wc -l
jstack -l pid |grep "Waiting on condition"|wc -l线程block问题一般是等待io、等待网络、等待监视器锁等造成，可能会导致请求超时、造成造成线程数暴涨导致系统502等。 如果出现这种问题，主要是关注jstack 出来的BLOCKED、Waiting on condition、Waiting on monitor entry等状态信息。 如果大量线程在"waiting for monitor entry"： 可能是一个全局锁阻塞住了大量线程。 如果短时间内打印的 thread dump 文件反映，随着时间流逝，waiting for monitor entry 的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区。 如果大量线程在"waiting on condition"：可能是它们又跑去获取第三方资源，迟迟获取不到Response，导致大量线程进入等待状态。 所以如果你发现有大量的线程都处在 Wait on condition，从线程堆栈看，正等待网络读写，这可能是一个网络瓶颈的征兆，因为网络阻塞导致线程无法执行。
gc时间过长
可以对JVM的参数调优，请参考2.4章节，正常来说java默认的回收机制是比较有效率的。G1收集器不一定会有提升
中间件日志
Tomcat在window版本的有些版本默认没有catalina.out日志，需要配置上，否则某些tomcat自身打出的日志就无迹可寻。正常tomcat启动需要检查2个日志是否正确配置： Catalina.out Localhost_access.log
进程远程监控
大部分服务是布置在linux服务器上的，并且linux没有安装图形界面，所以jdk自带的工具visualvm或者jconsole。所以想要对远程主机的java进程进行监控就需要配置远程监控jmx。
- 修改要访问的远程主机(Linux)tomcat相关文件
1.打开$CATALINA_HOME/bin/catalina.sh，在第一行注释后面添加，也就是#!/bin/sh后添加
export CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote
-Djava.rmi.server.hostname=192.168.. -Dcom.sun.management.jmxremote.port=8999
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=/opt/apache-tomcat-9.0.1/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=/opt/apache-tomcat-9.0.1/conf/jmxremote.access"2.备注
-Dcom.sun.management.jmxremote 启用JMX远程监控
-Djava.rmi.server.hostname=192.168.. 连接的服务器地址
-Dcom.sun.management.jmxremote.port=8999 jmx连接端口 可以自己定义
-Dcom.sun.management.jmxremote.ssl=false 是否ssl加密
-Dcom.sun.management.jmxremote.authenticate=true 远程连接需要密码认证(如为false后面的可省略)；
-Dcom.sun.management.jmxremote.password.file=/opt/apache-tomcat-9.0.1/conf/jmxremote.password 指定连接的用户名和密码配置文件
-Dcom.sun.management.jmxremote.access.file=/opt/apache-tomcat-9.0.1/conf/jmxremote.access 指定连接的用户所拥有权限的配置文件
连接服务器地址可以写为公网地址，linux使用命令 hostname -i 查看输出是否为公网地址，不是的话修改/etc/hosts文件，指向公网地址。3.其中jmxremote.password文件：
monitorRole roor123
controlRole root1234.jmxremote.access文件：
monitorRole readonly
controlRole readwrite5.重启Tomcat服务 6.使用命令 lsof -i:8999 查看端口号是否被监听 7.使用命令 netstat -antup |grep [pid] 会发现tomcat多开启了两个端口号 39143 38202。 因为当我们添加 -Dcom.sun.management.jmxremote.port 参数后不止会开启指定的端口，还会随机开启两个端口号，一个作为Jms的数据通讯端口，另一位作为jconsole的本地连接端口。从阿里云控制台开放指定端口和两个随机端口，如果开启有防火墙，同样放开，不然会导致连接不上。
- 在本地(Windows)创建jvisualvm--JMX连接 1.打开本地安装JDK_HOME/bin目录：{JAVA_HOME}\bin 2.打开：jvisualvm.exe 3.右键添加远程主机：
4.新建JMX连接
进程APM监控
例如OneAPM(收费)，使用java代理的方式把java的进程信息传递到服务器上并使用图形化的方式进行展现，比较可以直观的整体化展现。 也有免费的如果不想收费或者担心一些信息流出到其他服务器厂商，那可以自己搭建免费的。 oneapm(收费) 听云(收费)https://www.tingyun.com/tingyun_server.html SkyWalking 3(开源知名度高)http://skywalking.org Zabbix(免费) CAT (大众点评)(开源知名度高)https://github.com/dianping/cat Pinpoint(免费知名度高)https://github.com/naver/pinpoint BeeApm(开源) https://github.com/hao117/bee-apm (UI管理还在开发中)
