あなたのプログラムは、より速く、より安定したいが、システムは、多くの場合、バグの品種です、起動しませんか？Javaのパフォーマンスチューニングレイダーが来ています！
私は友人を持って、彼は一度、彼らは決して後の行には、同社のシステムのパフォーマンスチューニングを通じて完全な機能テストを行っていない私に言った、ラインは、任意のパフォーマンスの問題ええ、なぜ多くのシステムが持っていないされていませんパフォーマンスをチューニング？
その時私は、あなたの会社が12306でない場合は、上のオンラインシステムのパフォーマンスの最適化それをしない、彼に1に答える何が起こるかをしようとします。
あなたの場合は、どのようにそれに答えるでしょうか？今日、私たちは、あなたがこれらの質問を見つけることができるように望んでいた、このトピックについてのおしゃべり：なぜ我々はパフォーマンスチューニングを行う必要がありますか？あなたはやって始めたのはいつですか？パフォーマンスチューニングは、標準では、参照することができていないのですか？
なぜパフォーマンスチューニングを行いますか？
あなたがオンライン製品パフォーマンステストを通過しなかった場合、それは×××のように、あなたは、問題が発生した場合の制限は、それが負担することができる場所、あなたが知らない知らないです。いくつかのパフォーマンスの問題は自然に分解し、特定の時間に、ゆっくりと生成蓄積する時間であり、より多くのパフォーマンスの問題は、例えば、によって引き起こされるトラフィックの変動、ユーザの活動によって引き起こされる、または同社の製品は、バラ、もちろんがあるかもしれません半死後の製品ラインは、多くのトラフィックされていないので、風雲×××を引き起こしませんでした。
今イベント、プロダクトマネージャーや上司を行うには、あなたのシステムは、あなたが何百何千人ものユーザーを訪問したとシステムがイベントの圧力に耐えることができるかどうか尋ね期待伝えたとします。あなたはシステムのパフォーマンスを自分の状況がわからない場合は、唯一恐る恐るそれについて問題がない場合もあり、上司に答え。
だから、どちらかのパフォーマンスチューニングを行い、この質問は実際には非常に良い答えです。すべてのシステム開発が完了した後に、多かれ少なかれ、パフォーマンス上の問題があるでしょう、私たちが最初に行う必要があるが、このような等のストレステスト、可能な動作シナリオのシミュレーション、などの問題を公開する方法を、見つけることです、その後、パフォーマンスチューニングを通じて、これらを解決するために問題。
あなたがアプリケーションとの情報の特定の部分を照会する場合たとえば、あなたが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などの直接的な指標として。