`
ganlv
  • 浏览: 33604 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论
文章列表
       本节主要描述关于垃圾回收器性能的三个指标,三个关于垃圾回收器优化的基本原则,以及优化HotSpot VM的垃圾回收器的信息收集,在这些指标中权衡以及信息的收集是非常重要的。 性能指标      吞吐量:衡量垃圾回收器运行在性能峰值的时候不需要关心垃圾回收器暂停的时间或者需要占用内存的能力。      延迟:衡量垃圾回收器最小化甚至消灭由垃圾回收器引起的暂停时间和应用抖动的能力。      内存占用:衡量为了高效的运行,垃圾回收器需要的内存。            一项指标的提升,往往需要牺牲其他一项或者两项指标。换一句话说,一项指标的妥协通常是为了支持提升其他一项或 ...
选择JVM部署模型    JVM部署模型的选择总体来说就是决定应用是部署在单个JVM实例还是多个JVM实例上(这里简单举例说明一下JVM实例,比如:我们常用eclipse开发,启动一个eclipse就是启动了一个JVM实例,然后在JVM中运行一个main程 ...
   现代JVM是一个具有灵活适应各种应用能力的软件,尽管很多应用能够在JVM的默认配置下运行良好,但是有些应用还是需要优化JVM配置以达到其性能要求。由于各种各样的应用能够运行在现在JVM上面,所以大量的JVM选项可以配置来提升应用的性能。不幸的是,对一个应用而言优化得很好的JVM配置,对应另外的应用不一定适合。所以,真正理解怎样优化JVM配置是非常有必要的。    优化现代JVM是一门很大的艺术,但是理解和应用一些基本知识能够让优化JVM的任务变得更加简单。本章就是介绍这些基本知识和一些常规的步骤去优化Java HotSpot虚拟器。为了更好的理解本章的内容,你应该对JVM和垃圾回收器 ...
边缘问题    在某些场景下,按照前面的一步步优化指导无法产生效果。这一节说明一下这些情况。    一些应用分配了一些少量的非常大的长时间存活的对象。这样的场景需要需要young代的空间比old代更大。    一些应用会经历很少的对象转移。这样的场景可能需要old代的空间远远大于存活对象的大小,由于old的占用量增长率很小。    一些应用有小延迟需求,会使用CMS垃圾回收器,而且使用小young代空间(以致于MinorGC时间更短),以及大的old代空间。在这种配置下,对象会快速的从young代移动到old代,替代了高效老化对象。另外,CMS垃圾回收移动后的对象 ...
   如果你已经进行完了前面的步骤了,那么你应该知道这是最后一步了。在这一步里面,你需要测试应用的吞吐量和为了更高的吞吐量而优化JVM。    这一步的输入就是应用的吞吐量性能要求。应用的吞吐量是在应用层面衡量而不是在JVM层面衡量,因此,应用必须要报告出一些吞吐量指标或者应用的某些操作的吞吐量性能指标。观察到的吞吐量指标然后用可以用来和应用需要的性能指标进行比较,如果达到或者超过要求,那么这一步就完成了。如果你需要更好的吞吐量的话,有一些JVM优化可以去做。    这一步的另外一个输入就是,有多少内存可以供应用使用,就想前面说的GC最大化内存原则,越多可用的内存,性能就更好。这 ...
CMS垃圾回收器周期       一旦young的空间大小(包含eden和survivor空间)已经完善得满足应用对MinorGC产生延迟要求,注意力可以转移到优化CMS垃圾回收器,降低最差延迟时间的时间长度以及最小化最差延迟的频率。目标是保持可用的old代空间和并发垃圾回收,避免stop-the-world压缩垃圾回收。    stop-the-world压缩垃圾回收是垃圾回收影响延迟的最差情况,对某些应用来说,恐怕无法完全避免开这些,但是本节提供的优化信息至少可以减少他们的频率。    成功的优化CMS垃圾回收器需要达到的效果是old代的里面的垃圾回收的效率要和 ...
    本节的目标是做一些优化以满足对应用对延迟的需求。这次需要几个步骤,包括完善Java堆大小的配置,评估垃圾回收占用的时间和频率,也许还要尝试切换到不同的垃圾回收器,以及由于使用了不同的垃圾回收器,需要重新优化Java堆空间大小。     这一步有如下可能的结果:     1、应用的延迟需求被满足了。如果这一步的优化操作满足了应用的延迟需求,你可以继续下一步优化(优化吞吐量)。     2、应用的延迟需求未被满足。如果这一步的优化操作未能满足延迟需求,你可能需要重新看看延迟需求是否合理或者修改应用程序。一些可能的问题可以帮助改善应用的延迟问题:     a、优化 ...
   排版太难看了,另外在CSDN上写了:http://blog.csdn.net/zhoutao19872/article/details/7771962     到目前为止,还没有做明确的优化工作。只是做了初始化选择工作,比如说:JVM部署模型、JVM运行环境、收集哪些垃圾回收器的信息以及需要遵守垃圾回收原则。这一步将介绍如何评估应用需要的内存大小以及Java堆大小。首先需要判断出应用存活的数据的大小,存活数据的大小是决定配置应用需要的Java堆大小的重要条件,也能够决定是否需要重新审视一下应用的内存需求或者修改应用程序以满足内存需求。      注意:存活数据是指,应用处于 ...
两件2B的事情 1、域名备案:有人通知我域名备案需要接入空间商,然后以为没有什么大不了的事情,就置之不理,今天收到短信说我的备案已经被注销,这个时候才想起来没有去处理别人提供了的信息,导致了大麻烦。追根到底还是自己太懒惰,不愿意主动沟通,主动的去发现问题的根源,懒惰害死人。 2、为了解决一个问题,先写好了一个程序,然后认为在预发布环境下无法使用,然后搞出了一个更复杂的方案,再然后是复杂方案搞不来,然我去预发环境处理,又回到了最初的方案,关键是最初的方案还是管用的。浪费了一天时间,而且还给客户方造成了很大的痛苦。   增对上面的问题,两个根本点都是自己不去主动的沟通。沟通真的很重要。主动验 ...
 数据迁移程序不是一个项目正常的功能点,但是是一个项目上线和正常运行最重要的保证之一。好的数据迁移程序必须要做到以下几个点: 1、在大数据量的情况,单个数据的失败,不会影响后面数据继续进行。 2、纪录失败的数据。 3、能够修补失败数据,保证数据100%的迁移。
产品和运营如何平衡,运营活动往往都在破坏产品的结构,搞得产品乱七八糟。受不了了
      实践scrum有一段时间了,过去的一些日子里,感觉还不错,不过在组织架构调整以后,很多事情发生了变化,曾经很有节奏感的东西都丢了。很多很好的实践的放弃了,越走越不像那么一回事了,责任肯定在我的身上,在出现了问题没有及时的和团队沟通,没有把握好与上级的沟通。        另外,最近需求很混乱。产生了一个想法,一个团队的节奏感,很大程度的来源与产品经理,产品经理提出的需求总是一些碎片,一些临时需求必然导致混乱。如果越到不靠谱的产品经理,必须要有人站出来,把该做和不该的事情给理顺了。

20110520

这个特殊的日子,没有过出特别的感觉。   只是项目可能要延期了,主要是依赖方不稳定,当小白鼠不好当啊。
每次做设计的时候,一定要在满足功能之后,考虑稳定性和性能问题。 如果性能和稳定性问题解决好,才能更好的提高技术能力。   中心化系统和非中心化系统的方案不一样,中心化系统,绝对可以采用本地缓存和页面缓存,这样可以提高系统的性能。非中心化系统要采用本地缓存不太靠谱,只能采用集中的式的缓存,这样数据一致性容易保证一些,就是会消耗网络传输。   其实大多数系统,都有一些中心化数据,而且这些数据极有可能是热点数据,所以把中心化数据缓存在本地,是一个有效提高性能的思路。
       终于开始重视代码质量,但是关于代码如何写得更高的质量依旧非常的困惑和不解。最近希望尝试通过测试驱动开发的方式来提高自己的代码质量,尝试了几天了,中间虽然有的过程会走回老路子,总是会忘记先写测试再写代码,尤其是在改问题的时候,写新功能倒不会出现这样的问题,能够很好的控制,思维习惯还需要继续去养成。        在测试驱动开发的过程中,最难的如何做到小步前进,有时候会发现写一个功能的时候迈出的步子过大,就会导致单元测试不全面,导致单元测试的覆盖率不够,尤其是逻辑覆盖率。 所以想到一个过程,是否能够预先想好要处理的情形,然后编写好测试用例,然后把测试用例转变成单元测试代码,测试用 ...
Global site tag (gtag.js) - Google Analytics