java 性能优化实践——性能测试反模式

		/**
         * java 性能优化实践
         *  性能测试模式和反模式
         *      @性能测试反模式
         *          始终将性能调优视为一个客观的过程，在计划阶段的早期就设定精确的目标
         *          人为因素或者沟通因素，而不是技术方面的原因导致应用程序出错
         *
         *          Why Developer Making Bad Technology Choices
         *              #厌倦
         *                  对某个角色感到厌倦
         *                  不会出现太多时间，可以找新的角色和挑战
         *                  增加软件程序的复杂度，利用好的方法又能不导致问题的出现
         *              #填充简历
         *                  让新的技能帮助自己，完全忘记了这个持久的影响带来的副作用
         *
         *              #同事压力
         *                  做出选择时，如果关注点没有得到表达或讨论，做出的技术决策往往是糟糕的
         *                  负担症候群，竞争过剩
         *                  导致没有充分探讨所有后果的情况下就仓促做出关键决定
         *
         *              #缺乏理解
         *                  因为没有了解当前工具的全部功能，开发人员可能会引入新的工具帮助解决问题
         *                  然后引入更多技术复杂性也必须考虑与当前工具的实际功能相平衡
         *                  引入技术能够很快速的融合到生产链中，这是重要的借鉴能力
         *
         *              #被错误理解的问题/不存在的问题
         *                  特定的技术解决特定的问题，但是缺乏对问题空间本身进行充分研究
         *                  整理这些性能指标有助于更好的理解问题
         *
         *              @避免反模式
         *                  关于技术问题的交流对团队的所有参与者公开，鼓励大家参与——重要
         *                  在事情不清楚的地方，收集事实证据和研究原型可以帮助指导团队做出决策
         *      @性能反模式目录
         *          @被热门技术分心
         *              通过测量确定瓶颈的真正位置
         *              确保围绕新组件有足够的日志
         *              不能只看简化的演示，还要看最佳实践
         *              确保团队了解新技术，能够建立最佳实践目标
         *
         *          @被简单分心
         *              简单部分和系统整体剖析
         *                  原始开发人员也可能只了解自己写的部分，并不理解整个系统的过程
         *                  对于不同的系统组件，由于没有进行知识共享和结对编程，从而导致形成单一领域的专家
         *                  --
         *                  @有可能因为不愿意走出舒适区的情况下达到预期目标
         *                  确保开发人员了解系统的所有组件
         *
         *          @专业人才也需要共享和成为一份子
         *              任何问题都少不了测量和研究——如果我们希望解决问题的话
         *
         *          @行业调优方法
         *              对于会给系统的最重要方面造成直接影响的技术，只应用其中经过良好测试并充分理解的技术
         *
         *              在用户验收测试阶段寻找和尝试参数，对于任何修改，重要的是证明并描述其好处
         *              开发人员，运维人员DevOps团队一起审查和讨论配置
         *
         *          @驴的错误
         *              抑制住急于得出结论的压力
         *              经常使用执行分析
         *              所有干系人员公布分析结果——鼓励更精确的了解问题的原因
         *
         *          @忽略大局
         *              忘记小的修改对于整体的影响
         *              JVM有数百个开关——多尝试推荐配置
         *              性能调优是一项统计性活动，依赖于非常具体的执行上下文
         *              ————
         *              对每个改动进行测量
         *              生产环境和用户环境具有相同特定的配置进行测试
         *              让别人验证你的推理
         *              大家一起讨论我们的结论
         *              最终做出决定的CEO
         *         @用户验收环境不是本地计算机
         */