1、Java虚拟机运行时的数据区

2、常用的内存区域调节参数

-Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制

-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小 + 老生代大小 + 永久代大小。
在保证堆大小不变的情况下，增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

-Xss：每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。一般小的应用， 如果栈不是很深， 应该是128k够用的，大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"-Xss is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。

-XX:PermSize：设置永久代(perm gen)初始值。默认值为物理内存的1/64。

-XX:MaxPermSize：设置持久代最大值。物理内存的1/4。

3、内存分配方法

1）堆上分配   2）栈上分配  3）堆外分配（DirectByteBuffer或直接使用Unsafe.allocateMemory,但不推荐这种方式）

4、监控方法

1）系统程序运行时可通过jstat –gcutil来查看堆中各个内存区域的变化以及GC的工作状态；
2）启动时可添加-XX:+PrintGCDetails  –Xloggc:<file>输出到日志文件来查看GC的状况；
3）jmap –heap可用于查看各个内存空间的大小；

5）断代法可用GC汇总

一、新生代可用GC

1）串行GC(Serial Copying)：client模式下默认GC方式，也可通过-XX:+UseSerialGC来强制指定；默认情况下 eden、s0、s1的大小通过-XX:SurvivorRatio来控制，默认为8，含义
为eden:s0的比例，启动后可通过jmap –heap [pid]来查看。

      默认情况下，仅在TLAB或eden上分配，只有两种情况下会在老生代分配：
      1、需要分配的内存大小超过eden space大小；
      2、在配置了PretenureSizeThreshold的情况下，对象大小大于此值。

      默认情况下，触发Minor GC时：
      之前Minor GC晋级到old的平均大小 < 老生代的剩余空间 < eden+from Survivor的使用空间。当HandlePromotionFailure为true，则仅触发minor gc；如为false，则触发full GC。

      默认情况下，新生代对象晋升到老生代的规则：

     1、经历多次minor gc仍存活的对象，可通过以下参数来控制：以MaxTenuringThreshold值为准，默认为15。
     2、to space放不下的，直接放入老生代；

2）并行GC（ParNew）：CMS GC时默认采用，也可采用-XX:+UseParNewGC强制指定；垃圾回收的时候采用多线程的方式。

3）并行回收GC(Parallel Scavenge)：server模式下默认的GC方式，也可采用-XX:+UseParallelGC强制指定；eden、s0、s1的大小可通过-XX:SurvivorRatio来控制，但默认情况下
以-XX:InitialSurivivorRatio为准，此值默认为8，代表的为新生代大小 : s0，这点要特别注意。

      默认情况下，当TLAB、eden上分配都失败时，判断需要分配的内存大小是否 >= eden space的一半大小，如是就直接在老生代上分配；

      默认情况下的垃圾回收规则：

      1、在回收前PS GC会先检测之前每次PS GC时，晋升到老生代的平均大小是否大于老生代的剩余空间，如大于则直接触发full GC；
      2、在回收后，也会按照上面的规则进行检测。

      默认情况下的新生代对象晋升到老生代的规则：
     1、经历多次minor gc仍存活的对象，可通过以下参数来控制：AlwaysTenure，默认false，表示只要minor GC时存活，就晋升到老生代；NeverTenure，默认false，表示永不晋升到老生代；上面两个都没设置的情冴下，如UseAdaptiveSizePolicy，启动时以InitialTenuringThreshold值作为存活次数的阈值，在每次ps gc后会动态调整，如不使用UseAdaptiveSizePolicy，则以MaxTenuringThreshold为准。
     2、to space放不下的，直接放入老生代。

     在回收后，如UseAdaptiveSizePolicy，PS GC会根据运行状态动态调整eden、to以及TenuringThreshold的大小。如果不希望动态调整可设置-XX:-UseAdaptiveSizePolicy。如希望跟踪每次的变化情况，可在启劢参数上增加： PrintAdaptiveSizePolicy。

二、老生代可用GC

1、串行GC(Serial Copying)：client方式下默认GC方式，可通过-XX:+UseSerialGC强制指定。

    触发机制汇总：
   1）old gen空间不足；
   2）perm gen空间不足；
   3）minor gc时的悲观策略；
   4）minor GC后在eden上分配内存仍然失败；
   5）执行heap dump时；
   6）外部调用System.gc，可通过-XX:+DisableExplicitGC来禁止。

2、并行回收GC(Parallel Scavenge)： server模式下默认GC方式，可通过-XX:+UseParallelGC强制指定； 并行的线程数为当cpu core<=8 ? cpu core : 3+(cpu core*5)/8或通过-XX:ParallelGCThreads=x来强制指定。如ScavengeBeforeFullGC为true（默认值），则先执行minor GC。

3、并行Compacting：可通过-XX:+UseParallelOldGC强制指定。

4、并发CMS：可通过-XX:+UseConcMarkSweepGC来强制指定。并发的线程数默认为:( 并行GC线程数+3)/4，也可通过ParallelCMSThreads指定。

    触发机制：
    1、当老生代空间的使用到达一定比率时触发；

     Hotspot V 1.6中默认为65%，可通过PrintCMSInitiationStatistics（此参数在V 1.5中不能用）来查看这个值到底是多少；可通过CMSInitiatingOccupancyFraction来强制指定，默认值并不是赋值在了这个值上，是根据如下公式计算出来的： ((100 - MinHeapFreeRatio) +(double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0; 其中,MinHeapFreeRatio默认值： 40   CMSTriggerRatio默认值： 80。

     2、当perm gen采用CMS收集且空间使用到一定比率时触发；

     perm gen采用CMS收集需设置：-XX:+CMSClassUnloadingEnabled   Hotspot V 1.6中默认为65%；可通过CMSInitiatingPermOccupancyFraction来强制指定，同样，它是根据如下公式计算出来的：((100 - MinHeapFreeRatio) +(double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0; 其中，MinHeapFreeRatio默认值： 40    CMSTriggerPermRatio默认值： 80。

      3、Hotspot根据成本计算决定是否需要执行CMS GC；可通过-XX:+UseCMSInitiatingOccupancyOnly来去掉这个动态执行的策略。
      4、外部调用了System.gc，且设置了ExplicitGCInvokesConcurrent；需要注意，在hotspot 6中，在这种情况下如应用同时使用了NIO，可能会出现bug。

6、GC组合

1）默认GC组合

2）可选的GC组合

7、GC监测

1）jstat –gcutil [pid] [intervel] [count]
2）-verbose:gc // 可以辅助输出一些详细的GC信息；-XX:+PrintGCDetails // 输出GC详细信息；-XX:+PrintGCApplicationStoppedTime // 输出GC造成应用暂停的时间
-XX:+PrintGCDateStamps // GC发生的时间信息；-XX:+PrintHeapAtGC // 在GC前后输出堆中各个区域的大小；-Xloggc:[file] // 将GC信息输出到单独的文件中，建议都加上，这个消耗不大，而且对查问题和调优有很大的帮助。gc的日志拿下来后可使用GCLogViewer或gchisto进行分析。
3）图形化的情况下可直接用jvisualvm进行分析。

4）查看内存的消耗状况

      （1）长期消耗，可以直接dump，然后MAT(内存分析工具)查看即可

      （2）短期消耗，图形界面情况下，可使用jvisualvm的memory profiler或jprofiler。

8、系统调优方法

步骤：1、评估现状 2、设定目标 3、尝试调优 4、衡量调优 5、细微调整

设定目标：

1）降低Full GC的执行频率？
2）降低Full GC的消耗时间？
3）降低Full GC所造成的应用停顿时间？
4）降低Minor GC执行频率？
5）降低Minor GC消耗时间？
例如某系统的GC调优目标：降低Full GC执行频率的同时，尽可能降低minor GC的执行频率、消耗时间以及GC对应用造成的停顿时间。

衡量调优：

1、衡量工具
1）打印GC日志信息：-XX:+PrintGCDetails –XX:+PrintGCApplicationStoppedTime -Xloggc: {文件名}  -XX:+PrintGCTimeStamps
2）jmap：（由于每个版本jvm的默认值可能会有改变，建议还是用jmap首先观察下目前每个代的内存大小、GC方式） 
3）运行状况监测工具：jstat、jvisualvm、sar 、gclogviewer

2、应收集的信息
1）minor gc的执行频率；full gc的执行频率，每次GC耗时多少？
2）高峰期什么状况？
3）minor gc回收的效果如何？survivor的消耗状况如何，每次有多少对象会进入老生代？
4）full gc回收的效果如何？（简单的memory leak判断方法）
5）系统的load、cpu消耗、qps or tps、响应时间

QPS每秒查询率：是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。在因特网上，作为域名服务器的机器性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
TPS(Transaction Per Second)：每秒钟系统能够处理的交易或事务的数量。

尝试调优：

注意Java RMI的定时GC触发机制，可通过：-XX:+DisableExplicitGC来禁止或通过 -Dsun.rmi.dgc.server.gcInterval=3600000来控制触发的时间。

1）降低Full GC执行频率 – 通常瓶颈
老生代本身占用的内存空间就一直偏高，所以只要稍微放点对象到老生代，就full GC了；
通常原因：系统缓存的东西太多；
例如：使用oracle 10g驱动时preparedstatement cache太大；
查找办法：现执行Dump然后再进行MAT分析；

（1）Minor GC后总是有对象不断的进入老生代，导致老生代不断的满
通常原因：Survivor太小了
系统表现：系统响应太慢、请求量太大、每次请求分配的内存太多、分配的对象太大...
查找办法：分析两次minor GC之间到底哪些地方分配了内存；
利用jstat观察Survivor的消耗状况，-XX:PrintHeapAtGC，输出GC前后的详细信息；
对于系统响应慢可以采用系统优化，不是GC优化的内容；

（2）老生代的内存占用一直偏高
调优方法：① 扩大老生代的大小（减少新生代的大小或调大heap的 大小）；
减少new注意对minor gc的影响并且同时有可能造成full gc还是严重；
调大heap注意full gc的时间的延长，cpu够强悍嘛，os是32 bit的吗？
② 程序优化（去掉一些不必要的缓存）

（3）Minor GC后总是有对象不断的进入老生代
前提：这些进入老生代的对象在full GC时大部分都会被回收
调优方法：
① 降低Minor GC的执行频率；
② 让对象尽量在Minor GC中就被回收掉：增大Eden区、增大survivor、增大TenuringThreshold；注意这些可能会造成minor gc执行频繁；
③ 切换成CMS GC：老生代还没有满就回收掉，从而降低Full GC触发的可能性；
④ 程序优化：提升响应速度、降低每次请求分配的内存、

（4）降低单次Full GC的执行时间
通常原因：老生代太大了...
调优方法：1）是并行GC吗？   2）升级CPU  3）减小Heap或老生代

（5）降低Minor GC执行频率
通常原因：每次请求分配的内存多、请求量大
通常办法：1）扩大heap、扩大新生代、扩大eden。注意点：降低每次请求分配的内存；横向增加机器的数量分担请求的数量。

（6）降低Minor GC执行时间
通常原因：新生代太大了，响应速度太慢了，导致每次Minor GC时存活的对象多
通常办法：1）减小点新生代吧；2）增加CPU的数量、升级CPU的配置；加快系统的响应速度

细微调整：

首先需要了解以下情况：

① 当响应速度下降到多少或请求量上涨到多少时，系统会宕掉？

② 参数调整后系统多久会执行一次Minor GC，多久会执行一次Full GC，高峰期会如何？

需要计算的量：

①每次请求平均需要分配多少内存？系统的平均响应时间是多少呢？请求量是多少、多常时间执行一次Minor GC、Full GC？

②现有参数下，应该是多久一次Minor GC、Full GC，对比真实状况，做一定的调整；

必杀技：提升响应速度、降低每次请求分配的内存？

9、系统调优举例

     现象：1、系统响应速度大概为100ms；2、当系统QPS增长到40时，机器每隔5秒就执行一次minor gc，每隔3分钟就执行一次full gc，并且很快就一直full GC了；4、每次Full gc后旧生代大概会消耗400M，有点多了。

     解决方案：解决Full GC次数过多的问题

    （1）降低响应时间或请求次数，这个需要重构，比较麻烦；——这个是终极方法，往往能够顺利的解决问题，因为大部分的问题均是由程序自身造成的。

    （2）减少老生代内存的消耗，比较靠谱；——可以通过分析Dump文件（jmap dump），并利用MAT查找内存消耗的原因，从而发现程序中造成老生代内存消耗的原因。

    （3）减少每次请求的内存的消耗，貌似比较靠谱；——这个是海市蜃楼，没有太好的办法。

    （4）降低GC造成的应用暂停的时间——可以采用CMS GS垃圾回收器。参数设置如下：

     -Xms1536m -Xmx1536m -Xmn700m -XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection

     -XX:CMSMaxAbortablePrecleanTime=1000 -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC

    （5）减少每次minor gc晋升到old的对象。可选方法：1） 调大新生代。2）调大Survivor。3）调大TenuringThreshold。

      调大Survivor：当前采用PS GC，Survivor space会被动态调整。由于调整幅度很小，导致了经常有对象直接转移到了老生代；于是禁止Survivor区的动态调整了，-XX:-UseAdaptiveSizePolicy，并计算Survivor Space需要的大小，于是继续观察，并做微调…。最终将Full GC推迟到2小时1次。

10、垃圾回收的实现原理

      内存回收的实现方法：1）引用计数：不适合复杂对象的引用关系，尤其是循环依赖的场景。2）有向图Tracing：适合于复杂对象的引用关系场景，Hotspot采用这种。常用算法：Copying、Mark-Sweep、Mark-Compact。

      Hotspot从root set开始扫描有引用的对象并对Reference类型的对象进行特殊处理。
      以下是Root Set的列表：1）当前正在执行的线程；2）全局/静态变量；3）JVM Handles；4）JNI 【 Java Native Interface 】Handles；

      另外：minor GC只扫描新生代，当老生代的对象引用了新生代的对象时，会采用如下的处理方式：在给对象赋引用时，会经过一个write barrier的过程，以便检查是否有老生代引用新生代对象的情况，如有则记录到remember set中。并在minor gc时，remember set指向的新生代对象也作为root set。

     新生代串行GC(Serial Copying)：

     新生代串行GC(Serial Copying)完整内存的分配策略：

     1）首先在TLAB（本地线程分配缓冲区）上尝试分配；
     2）检查是否需要在新生代上分配，如需要分配的大小小于PretenureSizeThreshold，则在eden区上进行分配，分配成功则返回；分配失败则继续；
     3）检查是否需要尝试在老生代上分配，如需要，则遍历所有代并检查是否可在该代上分配，如可以则进行分配；如不需要在老生代上尝试分配，则继续；
     4）根据策略决定执行新生代GC或Full GC，执行full gc时不清除soft Ref；
     5）如需要分配的大小大于PretenureSizeThreshold，尝试在老生代上分配，否则尝试在新生代上分配；
     6）尝试扩大堆并分配；
     7）执行full gc，并清除所有soft Ref，按步骤5继续尝试分配。  

     新生代串行GC(Serial Copying)完整内存回收策略
     1）检查to是否为空，不为空返回false；
     2）检查老生代剩余空间是否大于当前eden+from已用的大小，如大于则返回true，如小于且HandlePromotionFailure为true，则检查剩余空间是否大于之前每次minor gc晋级到老生代的平均大小，如大于返回true，如小于返回false。
     3）如上面的结果为false，则执行full gc；如上面的结果为true，执行下面的步骤；
     4）扫描引用关系，将活的对象copy到to space，如对象在minor gc中的存活次数超过tenuring_threshold或分配失败，则往老生代复制，如仍然复制失败，则取决于HandlePromotionFailure，如不需要处理，直接抛出OOM，并退出vm，如需处理，则保持这些新生代对象不动；

    新生代可用GC-PS

    完整内存分配策略
    1）先在TLAB上分配，分配失败则直接在eden上分配；
    2）当eden上分配失败时，检查需要分配的大小是否 >= eden space的一半，如是，则直接在老生代分配；
    3）如分配仍然失败，且gc已超过频率，则抛出OOM；
    4）进入基本分配策略失败的模式；
    5）执行PS GC，在eden上分配；
    6）执行非最大压缩的full gc，在eden上分配；
    7）在旧生代上分配；
    8）执行最大压缩full gc，在eden上分配；
    9）在旧生代上分配；
    10）如还失败，回到2。

   最悲惨的情况，分配触发多次PS GC和多次Full GC，直到OOM。

   完整内存回收策略
   1）如gc所执行的时间超过，直接结束；
   2）先调用invoke_nopolicy
       2.1 先检查是不是要尝试scavenge；
       2.1.1 to space必须为空，如不为空，则返回false；
       2.1.2 获取之前所有minor gc晋级到old的平均大小，并对比目前eden+from已使用的大小，取更小的一个值，如老生代剩余空间小于此值，则返回false，如大于则返回true；
       2.2 如不需要尝试scavenge，则返回false，否则继续；
       2.3 多线程扫描活的对象，并基亍copying算法回收，回收时相应的晋升对象到旧生代；
       2.4 如UseAdaptiveSizePolicy，那么重新计算to space和tenuringThreshold的值，并调整。
   3）如invoke_nopolicy返回的是false，或之前所有minor gc晋级到老生代的平均大小 > 旧生代的剩余空间，那么继续下面的步骤，否则结束；
   4）如UseParallelOldGC，则执行PSParallelCompact，如不是UseParallelOldGC，则执行PSMarkSweep。

    老生代并行CMS GC：

    优缺点：

    1） 大部分时候和应用并发进行，因此只会造成很短的暂停时间；
    2）浮动垃圾，没办法，所以内存空间要稍微大一点；
    3）内存碎片，-XX:+UseCMSCompactAtFullCollection 来解决；
    4） 争抢CPU，这GC方式就这样；
    5）多次remark，所以总的gc时间会比并行的长；
    6）内存分配，free list方式，so性能稍差，对minor GC会有一点影响；
    7）和应用并发，有可能分配和回收同时，产生竞争，引入了锁，JVM分配优先。

11、TLAB的解释

     堆内的对象数据是各个线程所共享的，所以当在堆内创建新的对象时，就需要进行锁操作。锁操作是比较耗时，因此JVM为每个线在堆上分配了一块“自留地”——TLAB(全称是Thread Local Allocation Buffer)，位于堆内存的新生代，也就是Eden区。每个线程在创建新的对象时，会首先尝试在自己的TLAB里进行分配，如果成功就返回，失败了再到共享的Eden区里去申请空间。在线程自己的TLAB区域创建对象失败一般有两个原因：一是对象太大，二是自己的TLAB区剩余空间不够。通常默认的TLAB区域大小是Eden区域的1%，当然也可以手工进行调整，对应的JVM参数是-XX:TLABWasteTargetPercent。

参考文献：

1、Sun JDK 1.6 GC（Garbage Collector）  作者：毕玄

1、业主、总集成商、监理单位、承建单位、产品供货单位的沟通协调问题。首先，在与业主的沟通方面，最初较为混乱，主要原因是没有形成统一的沟通结构与机制，在最初的近三个月的时间里导致项目推进速度非常缓慢。经与业主单位沟通，制定了工程的沟通方案，建立了沟通组织结构。主要内容是在业主单位方面建立了项目实施办，项目实施办对部领导组成的项目办负责，明确了项目办与实施办的责任，由实施办协调信息中心各处室共同推进项目工作；并且在信息中心内部推行“承诺书”也就是各处室均对工程的建设内容进行承诺并与绩效挂钩。其次，总集成商、总监理商与实施办沟通，实施办与相关处室沟通，承建商与产品供货单位在技术上接受总集成商的指导与约束；在流程的规范性上接受总监理商的指导与约束；在业务上接受信息中心负责处室的约束。由此，通过沟通方案建立与推行，项目的沟通协调方面才进入了正轨，项目的推进速度明显加快。

2、用户单位对项目的支持度等方面的问题。某些用户单位对所建设的项目并没有强烈的需求，持可有可无或最好没有的态度，但在工程的初设中这些项目又是必须建设的内容。因此，在项目的实施的过程中，这写用户单位对项目的各项工作均持消极态度，使得项目无法正常推进。例如，有些用户单位不组织本单位人员配合需求调研，不组织下属各省级单位进行系统试运行，不组织本单位人员进行用户测试等。对于这些问题往往系统承建商方面已无法推动，需要通过实施办与项目办层面与用户单位沟通协商一致后才能继续开展工作。

3、部本级项目与省级项目的协调推进问题。由于在工程的可研中包含各省的项目建设，各省建设的进度对整体项目的最终验收具有制约作用。目前，各省的建设情况各不一致，有的已经完成，有的正在建设过程中，有的资金尚未批复。。。

二、技术架构方面

1、应用系统部署架构问题。在09年底的时候，在应用系统部署架构出现了一个“互联网区应用系统访问Oracle RAC数据库时断时续问题”，此问题先后持续了4到5个月，制约了项目的建设进度（期间采用了其他方式，尽量减少了损失）。原因1，在进行整体应用系统部署架构设计时，尚未进行相应产品的招标，因此无法明确具体的产品（各产品在具体的实现层面有差别，这些差别可能影响部署架构的实现）。原因2，各厂商均具有专业领域的知识背景，但对各知识领域之间的把握较少，因此很可能在边缘领域出现问题。原因3，由于本项目为大型的电子政务项目，涉及的专业知识领域和技术手段非常繁杂，在设计与测试过程中非常困难。在实施办与总集的总体协调下，经过多次的评审与大量的测试，对应用系统部署架构进行了调整，使问题成功解决。此类问题的解决方法是由总集成商牵头，召集相关的承建单位，如网络集成商、安全集成商、数据库提供商。。。共同讨论分析，制定问题的排查方案，并按照方案查找问题的原因。待问题的原因查找清楚后，再由总集成商召集相关承建商共同讨论提出解决方法，经实施办审核通过（如重大技术问题可由实施办召集专家进行评审确定）。

2、部分系统试运行阶段性能低下与生产环境问题排查困难等。一方面，工程所用到的技术非常复杂，采用了大量的设备，如 Oralce RAC集群，存储，IBM小型机、负载均衡集群等，此种环境很难有一个企业（如承建单位或第三方测试单位）复制。因此，无论是承建单位还是第三方测试单位所进行的测试均无法完全反映生产环境下的性能指标。另一方面，此种生产环境也是初次搭建，其技术可行性只停留在理论层面，期间的技术细节无法完全在设计阶段考虑到，只能通过一段时间的系统试运行才能够暴露与完善。当然，如果能够在系统进行初步设计时，能够考虑搭建一套与生产环境完全或基本一致的测试环境，此问题将能够很方便的进行解决，也就是可以在测试环境中进行应用系统的压力测试与问题排查，待系统稳定后并满足用户要求时，再将系统迁移至正式的生产环境中，这种方式可以最大程度的保持生产环境的稳定性。

        以下内容结合了其他网友发表的内容，首先再次表示感谢。

        假设一个系统有2000个使用者（对于一般的企业系统，这个概念比较简单，就是指数据库中的用户总数，但对于网站型的系统而言，相对较为复杂，一般为注册用户和游客的总和），也就是说，该系统的用户总数是2000名，这个概念表示的是“系统用户数”。如果该系统具有“ 在线统计”功能，该功能一般用于记录系统中所有已经登录的用户（当然如果有一些系统功能同时也提供给未登录的用户使用，那么未登录的当前使用者也应记录进来），如果根据此统计结果得到最高峰时有500人在线，那么这个500就是所说的“同时在线用户数”。
    根据对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，考察具体的某一个时间点，在这500个“同时在线用户数”中，其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的 20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。
在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且为了方便，直接将业务并发用户数称为并发用户数。
（1） 计算平均的并发用户数： C = nL/T
（2） 并发用户数峰值： C’ ≈ C+3根号C
公式（1）中C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
公式（2）给出了并发用户数峰值的计算方式，其中C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
实例：
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
C = 400*4/8 = 200
C’≈200+3*根号200 = 242

       以下是测试所需的一些常用公式，仅供参考

        F=VU * R / T   R = T / TS

       其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间，TS为用户思考时间 。

1 、搭配草稿、蓝图两种用法的步骤为

1）  先画出 UML 草稿

2）  以 CASE 工具用正向工程转出程序码大纲

3）  修改程序码

4）  定期从程序码已 CASE 工具用反向工程转出 UML 设计模型

将 UML 视为草稿是在谈 [ 选择性 ] 。选择主要的模块进行讨论。

将 UML 视为蓝图是在谈 [ 完整性 ] 。这种做法可以用在所有 [ 细节 ] 的工作上，也可以针对特定的部分化出蓝图。

模型驱动开发架构（ Model Driven Architecture ， MDA ）： MDA 将 UML 视为程序语言的标准用法。 MDA 将开发分为两个主要部分，模型建立者会负责产生于平台无关的模型 （ Platform Independent Model ， PIM ）， PIM 代表与任何与特定格式无关的 UML 模型。然后工具可以把 PIM 转换为平台特有模型（ PSM ）， PSM 是在某个特定执行环境之上的模型，其他工具可以将 PSM 转换为某个平台之上的程序码。

UML 的创造者认为 UML 的本质在于超模型，图仅仅是超模型的展现而已。

个人推荐将UML作为草稿的用法，

UML2.0 中的图共有如下11种：

1、  活动图（activity diagram）

2、  类图（Class diagram）

3、  合作图（ communicationdiagram diagram ）：对象件的互动情形，焦点在连接关系上

4、  元件图（component diagram）元件结构与连接关系

5、  合成结构（composite structure）类别在执行期的合成情形（UML2 新增 ）

6、  配置图（deployment diagram）将工作成果配置到节点上

7、  互动概图（interaction overview diagram）混合时序图与活动图两者（UML2新增）

8、  对象图（object diagram）

9、  套件图（package diagram）编译器的阶层结构

10、  时序图（sequence diagram）对象间的互动情形，焦点在信息的先后顺序。

11、              状态机图（state machine diagram）说明事件在对象中的生命力，如何改变状态

12、              时序图（timing diagrame）对象间的互动情形（UML2新增）

13、              用例图（use case diagrame）说明使用者如何与系统进行交互

简介：JCL提供一个日志接口，同时兼顾轻量级和不依赖于具体的日志实现工具。

入门：JCL有两个基本的抽象类：Log(基本纪录器)和LogFactory(负责创建Log实例)。JCL寻找日志工具的过程如下：

一〉              寻找当前的factory中名叫org.apache. commons.logging.Log配置属性的值。

二〉              寻找系统属性中名叫org.apache.commons.logging.Log的值。

三〉              如果应用程序的CLASSPATH中有Log4j,这是用相关的包装类（wrapper）类（Log4Jlogger）.

四〉              如果应用程序运行在jdk1.4的系统中，使用相关的包装类(JDK1.4logger).

五〉              使用简易日志包装类（SimpleLog）.

使用logging:

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

public class MyClass{

private static Log log=LogFactory.getLog(this.CLASS);

…………………………

}

这些日志信息被送往日志器，如上例中的log。

Log接口中的方法：

定义日志信息的级别，按严重性有：

log.fatal(Object message);

log.fatal(Object message,Throwable t);

log.error(Object message);

log.error(Object message,Throwable t);

log.warn(Object message);

log.warn(Object message,Throwable t);

log.info(Object message);

log.info(Object message,Throwable t);

log.debug(Object message);

log.debug(Object message,Throwable t);

log.trace(Object message);

log.trace(Object message,Throwable t);

fatal:非常严重的错误，导致系统终止。期望这类信息被立即显示到状态控制台上。

Error:其他运行期错误或不是预期的条件。期望这类信息被立即显示到状态控制台上。

Warn:使用了不赞成使用的API、非常拙劣的使用了API、‘几乎就是错误’其他运行期不合需要和不合预期的状态（但没必要将其称为错误）。期望这类信息被立即显示到状态控制台上。

Info:运行期产生的有意义的事件。期望这类信息被立即显示到状态控制台上。

Debug:系统流程中的细节信息。期望这类信息仅被写入日志文件中。

Trace:更加细节的信息。期望这类信息仅被写入日志文件中。

用于代码保护(表示如果启用了某种日志信息级别)：

log.isFatalEnabled();

log.isErrorEnabled();

log.isWarnEnabled();

log.isInfoEnabled();

log.isDebugEnabled();

log.isTraceEnabled();

通常情况下，记录器的级别不低于info,通常情况下debug信息不应被写入log文件中。

工作机理：

一〉             生命周期：JCL LogFactory必须实现建立/断开到日志工具的连接，实例化/初始化/解构一个日志工具。

二〉             异常处理：JCL Log接口没有实现任何异常处理，对接口的实现必须捕获并处理异常。

记录器的设置：log4j时JCL的首选记录器：

参数	值域	默认值	说明
Log4j.configuration		Log4j.properties	指定配置文件的名字
Log4j.rootCategory	Priority[,appender].*		设定根记录器级别
Log4j.logger.	Debug,info,trace,error,fatal	设定这个记录器的级别
Log4j.appender..Threshold	priority	指定纪录设备的最低级别（console,files,sockets,others）

阳光咖啡 2005-09-07 11:33 发表评论

]]>