프로그램이보다 빠르고 안정적으로 원하는,하지만 시스템은 종종 버그의 다양한입니다, 시작하지? 자바 성능 튜닝 해적이오고있다!
나는 친구가, 그가 한 번, 그들은 결코 다음 줄에, 회사의 시스템 성능 조정을 통해 완전한 기능 테스트를 갈 나에게 말했다 라인은 성능 문제 그래, 왜 많은 시스템이 있나요되지 않았습니다 성능을 튜닝?
그 때 나는 당신의 회사는 12306입니다 않는 경우, 온라인 시스템 성능 최적화를하지 않는다, 그에게 한 대답 무슨 일이 일어날 지하려고합니다.
당신, 어떻게 당신은 그것을 대답 하시겠습니까? 오늘, 우리는 당신이이 질문을 알아낼 수있을 싶어,이 주제에 관해 채팅 : 왜 우리는 성능 튜닝을해야합니까? 당신은 일을 시작 했나요? 성능 조정은 표준을 참조 할 수 있습니다되지 않습니다?
왜 성능 조정을합니까?
당신이 온라인 제품 성능 테스트를 통과하지 않는 경우, 그것은 ×××처럼, 당신은 문제가 발생하면 한계가 견딜 수있는, 당신이 모르는 모르는 것입니다. 일부 성능 문제는 자연적으로 폭발 특정 시간에 천천히 생산 축적하는 시간이며, 더 많은 성능 문제는 예를 들어,로 인한 트래픽 변동, 사용자 활동에 의해 발생, 또는 회사의 제품 장미, 당연히있을 수 있습니다 반 죽은 후 제품 라인은 많은 트래픽되지 않았습니다, 그래서 Fengyun ××× 발생하지 않았다.
이제 시스템 이벤트, 제품 관리자를 할 생각이나 상사가 당신이 수백 수천 명의 사용자의 방문 및 시스템 이벤트의 압력을 견딜 수 있는지 여부를 물었다 기대 알려줍니다. 당신은 시스템의 성능을 자신의 상황을 알 수없는 경우에만 소심 그것에 대해 아무 문제가 없을 수 있습니다, 보스 대답했다.
그래서 하나가 성능 튜닝을,이 질문은 실제로 아주 좋은 대답이다. 개발 완료 후 모든 시스템이 더 많거나 적은, 성능에 문제가있을 것입니다, 우리가 먼저해야 할 것은 등 스트레스 테스트 가능한 운영 시나리오의 시뮬레이션과 같은 문제를 노출 할 수있는 방법을 찾는 것이다 다음 성능 조정을 통해이를 해결하기 위해 문제.
당신이 응용 프로그램과 어떤 정보를 쿼리 할 때 예를 들어, 이상 10 초 동안 기다릴 필요, 활동을 구입, 당신은 그래서 이벤트 페이지를 입력 할 수 없습니다. 당신은 시스템 응답이 가장 직접적이다 참조 요소의 성능을 반영 참조하십시오.
문제는 온라인 시스템에 표시되지 않는다는 응답한다면, 우리는 밖으로 튜닝 성능을하지 않는다되지 않습니다? 이야기를 당신을 제공합니다.
시스템 개발 부서 전에 내 전 클럽이 큰 하나님 온되면 그가 년에 회사에 왔기 때문에, 왜, 위대한 하나님이 그에게 전화, 그는 단 한 가지가 있고, 원래의 절반에 서버의 수를 줄이는 것입니다, 시스템의 성능은 또한 향상시킨다.
好的系统性能调优不仅仅可以提高系统的性能，还能为公司节省资源。这也是我们做性能调优的最直接的目的。
什么时候开始介入调优？
解决了为什么要做性能优化的问题，那么新的问题就来了：如果需要对系统做一次全面的性能监测和优化，我们从什么时候开始介入性能调优呢？是不是越早介入越好？
其实，在项目开发的初期，我们没有必要过于在意性能优化，这样反而会让我们疲于性能优化，不仅不会给系统性能带来提升，还会影响到开发进度，甚至获得相反的效果，给系统带来新的问题。
我们只需要在代码层面保证有效的编码，比如，减少磁盘 I/O 操作、降低竞争锁的使用以及使用高效的算法等等。遇到比较复杂的业务，我们可以充分利用设计模式来优化业务代码。例如，设计商品价格的时候，往往会有很多折扣活动、红包活动，我们可以用装饰模式去设计这个业务。
在系统编码完成之后，我们就可以对系统进行性能测试了。这时候，产品经理一般会提供线上预期数据，我们在提供的参考平台上进行压测，通过性能分析、统计工具来统计各项性能指标，看是否在预期范围之内。
在项目成功上线后，我们还需要根据线上的实际情况，依照日志监控以及性能统计日志，来观测系统性能问题，一旦发现问题，就要对日志进行分析并及时修复问题。
有哪些参考因素可以体现系统的性能？
上面我们讲到了在项目研发的各个阶段性能调优是如何介入的，其中多次讲到了性能指标，那么性能指标到底有哪些呢？
在我们了解性能指标之前，我们先来了解下哪些计算机资源会成为系统的性能瓶颈。
CPU：有的应用需要大量计算，他们会长时间、不间断地占用 CPU 资源，导致其他资源无法争夺到 CPU 而响应缓慢，从而带来系统性能问题。例如，代码递归导致的无限循环，正则表达式引起的回溯，JVM 频繁的 FULL GC，以及多线程编程造成的大量上下文切换等，这些都有可能导致 CPU 资源繁忙。
内存：Java 程序一般通过 JVM 对内存进行分配管理，主要是用 JVM 中的堆内存来存储 Java 创建的对象。系统堆内存的读写速度非常快，所以基本不存在读写性能瓶颈。但是由于内存成本要比磁盘高，相比磁盘，内存的存储空间又非常有限。所以当内存空间被占满，对象无法回收时，就会导致内存溢出、内存泄露等问题。
磁盘 I/O：磁盘相比内存来说，存储空间要大很多，但磁盘 I/O 读写的速度要比内存慢，虽然目前引入的 SSD 固态硬盘已经有所优化，但仍然无法与内存的读写速度相提并论。网络：网络对于系统性能来说，也起着至关重要的作用。如果你购买过云服务，一定经历过，选择网络带宽大小这一环节。带宽过低的话，对于传输数据比较大，或者是并发量比较大的系统，网络就很容易成为性能瓶颈。
异常：Java 应用中，抛出异常需要构建异常栈，对异常进行捕获和处理，这个过程非常消耗系统性能。如果在高并发的情况下引发异常，持续地进行异常处理，那么系统的性能就会明显地受到影响。
数据库：大部分系统都会用到数据库，而数据库的操作往往是涉及到磁盘 I/O 的读写。大量的数据库读写操作，会导致磁盘 I/O 性能瓶颈，进而导致数据库操作的延迟性。对于有大量数据库读写操作的系统来说，数据库的性能优化是整个系统的核心。
锁竞争：在并发编程中，我们经常会需要多个线程，共享读写操作同一个资源，这个时候为了保持数据的原子性（即保证这个共享资源在一个线程写的时候，不被另一个线程修改），我们就会用到锁。锁的使用可能会带来上下文切换，从而给系统带来性能开销。JDK1.6 之后，Java 为了降低锁竞争带来的上下文切换，对 JVM 内部锁已经做了多次优化，例如，新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除等。而如何合理地使用锁资源，优化锁资源，就需要你了解更多的操作系统知识、Java 多线程编程基础，积累项目经验，并结合实际场景去处理相关问题。
了解了上面这些基本内容，我们可以得到下面几个指标，来衡量一般系统的性能。
1、响应时间
响应时间是衡量系统性能的重要指标之一，响应时间越短，性能越好，一般一个接口的响应时间是在毫秒级。在系统中，我们可以把响应时间自下而上细分为以下几种：
数据库响应时间：数据库操作所消耗的时间，往往是整个请求链中最耗时的；
服务端响应时间：服务端包括 Nginx 分发的请求所消耗的时间以及服务端程序执行所消耗的时间；
网络响应时间：这是网络传输时，网络硬件需要对传输的请求进行解析等操作所消耗的时间；
客户端响应时间：对于普通的 Web、App 客户端来说，消耗时间是可以忽略不计的，但如果你的客户端嵌入了大量的逻辑处理，消耗的时间就有可能变长，从而成为系统的瓶颈。
2、吞吐量
在测试中，我们往往会比较注重系统接口的 TPS（每秒事务处理量），因为 TPS 体现了接口的性能，TPS 越大，性能越好。在系统中，我们也可以把吞吐量自下而上地分为两种：磁盘吞吐量和网络吞吐量。我们先来看磁盘吞吐量，磁盘性能有两个关键衡量指标。
接下来看网络吞吐量，这个是指网络传输时没有帧丢失的情况下，设备能够接受的最大数据速率。网络吞吐量不仅仅跟带宽有关系，还跟 CPU 的处理能力、网卡、防火墙、外部接口以及 I/O 等等紧密关联。而吞吐量的大小主要由网卡的处理能力、内部程序算法以及带宽大小决定。
3、计算机资源分配使用率
通常由 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 来表示资源使用率。这几个参数好比一个木桶，如果其中任何一块木板出现短板，任何一项分配不合理，对整个系统性能的影响都是毁灭性的。
4、负载承受能力
当系统压力上升时，你可以观察，系统响应时间的上升曲线是否平缓。这项指标能直观地反馈给你，系统所能承受的负载压力极限。例如，当你对系统进行压测时，系统的响应时间会随着系统并发数的增加而延长，直到系统无法处理这么多请求，抛出大量错误时，就到了极限。
总结
通过今天的学习，我们知道性能调优可以使系统稳定，用户体验更佳，甚至在比较大的系统中，还能帮公司节约资源。
그러나 프로젝트의 시작 부분에서, 우리는 뛰어난 코딩, 효율적이고, 좋은 프로그래밍을 보장하기 위해 시간에 맞춰, 성능을 최적화 조기에 개입 할 필요가 없습니다.
프로젝트가 완료되면, 우리는 시스템을 테스트 할 수 있습니다, 우리는 표준 성능 튜닝, 응답 시간, 처리량, 자원 할당 컴퓨터 사용, 하중지지 용량으로 다음과 같은 성과 지표를 사용할 수 있습니다.
프로젝트 내 자신의 경험을 되돌아 보면, 게임을 충전하는 전기 공급 시스템, 결제 시스템과 결제 시스템이 사용자 레벨이 만 레벨이며, 대규모 구매 활동의 모든 종류의 부담, 시스템의 성능은 그래서 매우 까다로운입니다. 좋은지 나쁜지 위의 표시등을 관찰하여 시스템의 성능을 결정뿐만 아니라, 또한, 반복을 업데이트하기 위해 완전히 시스템의 안정성을 보호해야합니다.
여기에서, 당신은 단지 처리량, 응답 시간을 비교하지 반복 개발의 비정상적인 버전이 있는지 확인한 후 성능 테스트, 시스템 성능을 자동화하여 참조 표준으로 시스템 성능 지표의 반복 버전 전에, 즉, 방법을 확장 이러한 직접적인 하중의 표시뿐만 아니라, 시스템 자원의 CPU 사용량과 같은, 그래서 메모리 사용량, 디스크 I / O, 네트워크 I / O 및 여러 간접 지표의 변화.