代码时光

jstack 是分析 JVM 线程问题的重要工具，可以帮助定位死锁、线程阻塞、CPU 占用过高等问题。状态的线程，并检查它们等待的锁。如果多个线程互相等待对方持有的锁，则可能存在死锁。状态的线程，并检查它们的调用栈，找出占用 CPU 的代码。FGC 为 1868，Full GC 次数过多，说明。状态的线程，并检查它们等待的条件或锁。这里其实我已经发现了我们内存泄露的问题~可以看到垃圾回收期的线程很活跃~在线程转储文件中，查找。在线程转储文件中，查找。在线程转储文件中，查找。

jstack 是分析 JVM 线程问题的重要工具，可以帮助定位死锁、线程阻塞、CPU 占用过高等问题。通过结合 top 和其他工具，可以更高效地分析线程状态和调用栈。

现实企业级Java应用开发、维护中，有时候我们会碰到下面这些问题：OutOfMemoryError，内存不足内存泄露线程死锁锁争用（Lock Contention）Java进程消耗CPU过高…这些问题在日常开发、维护中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。一、 jps(Java Virtual Machin

线上故障主要会包括 CPU、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如 jstack、jmap 等工具也是不囿于一个方面的问题的，基本上出问题就是 df、free、top 三连，然后依次 jstack、jmap 伺候，具体问题具体分析即可。CPU一般来讲我们首先会排查 CPU 方面的问题。CPU 异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁 GC 以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)

CPU磁盘内存GC问题网络线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top 三连，然后依次jstack、jmap伺候，具体问题具体分析即可。CPU一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(.

当UDP丢包的时候，我们正常情况下是增加各种缓冲区的大小，有调整内核缓冲区的，也有调整应用缓冲区的。但是还有另外一种方式，就是加速UDP数据包的处理速度。1.当前Linux网络应用程序问题运行在Linux系统上网络应用程序，为了利用多核的优势，一般使用以下比较典型的多进程/多线程服务器模型：首先需要单线程listen一个端口上，然后由多个工作进程/线程去accept()在同一个服务器套接字上。 但有以下两个瓶颈：单线程listener，在处理高速率海量连接时，一样会成为瓶颈多线程访问serv.

JVisualVM 简介VisualVM 是Netbeans的profile子项目，已在JDK6.0 update 7 中自带，能够监控线程，内存情况，查看方法的CPU时间和内存中的对 象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。在JDK_HOME/bin(默认是C:\Program Files\Java\jdk1.6.0_13\bin)目录下面，有一个jvisualvm.exe文件，双击打开，从UI上来看，这个软件是基于NetBeans开发的了。Vi

线上服务的GC问题，是Java程序非常典型的一类问题，非常考验工程师排查问题的能力。同时，几乎是面试必考题，但是能真正答好此题的人并不多，要么原理没吃透，要么缺乏实战经验。过去半年时间里，我们的广告系统出现了多次和GC相关的线上问题，有Full GC过于频繁的，有Young GC耗时过长的，这些问题带来的影响是：GC过程中的程序卡顿，进一步导致服务超时从而影响到广告收入。这篇文章，我将以一个FGC频繁的线上案例作为引子，详细介绍下GC的排查过程，另外会结合GC的运行原理给出一份实践指南，希望对你有所帮助

平时的工作中经常碰到很多疑难问题的处理，在解决问题的同时，有一些工具起到了相当大的作用，在此书写下来，一是作为笔记，可以让自己后续忘记了可快速翻阅，二是分享，希望看到此文的同学们可以拿出自己日常觉得帮助很大的工具，大家一起进步。Linux命令类tail最常用的tail -ftail -300f shopbase.log #倒数300行并进入实时监听文件写入模式grepgrep forest f.txt #文件查找grep forest f.txt cpf.txt #多文件查找gre

前言一般来说，每个公司对于JVM的参数都有规范的，甚至形成了一些公司层面的默认配置，如果遇到性能问题（比较特殊的使用场景），就会考虑从代码层次、JVM层次、甚至Linux服务器层次去进行优化。堆设置-Xms:初始堆大小-Xmx:最大堆大小-XX:NewSize=n:设置年轻代大小-XX:NewRatio=n:设置年轻代和年老代的比值。如n=3，表示年轻代与年老代比值为1：3，年轻代占整个年轻和代年老代的1/4-XX:SurvivorRatio=n:年轻代中Eden区与两个

当MySQL单表记录数过大时，增删改查性能都会急剧下降，可以参考以下步骤来优化：单表优化除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量：字段尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNEDVARCHAR的长度只分配

前言本文的目的不在于给出最佳配置，而是带领开发者，能够从实际情况出发，通过不断的调节tomcat和jvm参数，去发现吞吐量，平均响应时间和错误率等信息的变化，同时根据服务器的cpu和内存等信息，结合接口的业务逻辑，最好是测试使用率最高，并发最大，或者是最重要的接口(比如下单支付接口)，设置最优的tomcat和jvm配置参数。目的通过Tomcat性能优化可以提高网站的并发能力。Tomcat服务器在JavaEE项目中使用率非常高，所以在生产环境对Tomcat的优化也变得非常重要了。对于Tomcat的优