在开发、测试、线上运行的过程中，程序难免会出现问题，如果快速地定位程序的问题，是每个程序员的必修课。
当程序报错，最简单且快速的方法就是查询日志中的报错信息了；所以我们在敲代码的时候，一定不能对CheckedException只捕捉不处理。
首先不要忽略异常，第一可以在捕捉到异常后将日志信息输出，要么通过Throw或throws向上抛，让上层的代码进行处理；
接上，不要捕捉异常后，输出完日志又向上抛出异常，这样当查询定位错误时，会产生误导；
对于捕捉到的异常，最好可以精确地指出具体是什么异常，而不要用catch(Exceptione)替代；
如果选择了输出异常，那么就要把异常单独打印到一个日志文件中，否则你很可能需要在一大堆日志文件中翻阅查找；
另外，日志信息尽可能的详细，比如方法的入参、与其他系统交互的报文等等。
如果你能在日志文件中快速的找到报错信息的话，那么再定位错误程序就容易很多：
通常异常输出能看到报错的类、方法、甚至代码行数，可以先检查程序是不是有显而易见的错误；
如果是开发测试环境，可以通过IDE进行代码调试，如果错误每次都可以复现，那就是一个明显的BUG，如果是部分数据有问题，那么就要分析是程序不严谨，还是数据有问题；
如果是生成环境的话，我们很难进行线上调试，那么只能通过日志来进行具体的分析了，条件允许的话，可以把生产环境的数据拿下来进行检查和调试。
很多程序员会说，我的日志都很完善了，还需要监控么？我建议最好是有的，而且监控越完善越好。
首先，通过日志查询问题，通常都是业务人员或用户在操作过程中遇到问题，找到运维和开发之后，我们再去翻日志；如果有监控的话，可以实时地发现问题，提前解决问题。
第二，现在很多项目都不是单台部署，应用部署个几台、几十台甚至几百台都很常见，当发现问题之后，人肉翻日志已经不太现实了，如果有一个日志平台的话，那就会方便很多。
第三，很多公司的项目都是分布式架构、微服务架构，越来越多的服务都是链路调用，A系统调B系统，B系统再调C系统和D系统，这种情况下翻一个服务的访问链路，就需要从几个系统上拿日志，人肉运维是很费时费力的。
上面说到的各种错误，基本上是有明确的代码问题，不管是代码本身的问题，还是数据的问题导致代码报错，另外一种不是“显性”的异常（最终可能依然是代码的问题），比如内存使用过高、CPU使用过高、频繁FullGC、OOM等等，通常这一类的问题不好重现、定位困难。
如果有报错信息，首先还是要查找关键报错信息，比如java.lang.OutOfMemoryError:Javaheapspace，很明显就是堆溢出；
这时候你需要知道堆里面存的是什么，这样有助于你进行问题的排查：Java堆用于存储对象实例，如果有大量的对象无法被垃圾回收机制清除，那么超过堆容量限制之后，就会发生溢出；
我们可以使用内存映像分析工具，对堆储存快照进行分析；如果有内存泄漏，可以通过工具查看泄漏对象；如果不存在泄漏的话，可以检查代码中是否有递归、死循环等等。
当然，不同“部位”泄漏和溢出的原因都是不同的，需要具体分析。如果是CPU过高，可以通过系统命令来定位问题：
一般Java程序CPU过高，可能是这几种原因：死循环、计算比较密集、IO读写高、请求堵塞等等；
通过top命令，查看当前服务器占用CPU资源最多的进程，得到进程号PID=4454；
通过top-Hp4454查询4454进程中各个线程的资源使用率；比如有一个线程4492占用CPU特别高；
通过printf"%x\n"4492命令，把线程id转化为十六进制；4492的十六进制是118c；
使用jstack命令打印堆栈信息：jstack4454|grep-10118c；
根据占用CPU高的线程的堆栈信息，分析对应的代码在做什么操作，并进行优化。
