精確的字符串截取方法 java
发开项目需要，在网上找了很久都没有打到．于是自己动手写了一下．贡献出来给有需要的人．如果有什么问题可以加我ＭＳＮ：[email protected] 讨论讨论 源代码： /** * 截取字符串的前targetCount个字符 * @param str 被处理字符串 * @param targetCount 截取长度 * @version 1.1 * @author Strong Yuan * @return String */ public static String subContentStringOrialBytes(String str,int targetCount){ return subContentStringOrialBytes(str,targetCount,”…”); } /** * 获取指定长度字符串的字节长 * @param str 被处理字符串 * @param maxlength 截取长度 * @author Strong Yuan * @version 1.1 * @return String */ private static long getStringByteLength(String str,int […]
resin 3.1使用总结.
使用resin已经有四、五年了，但以前都是做一些小系统，resin的压力并不大，近段时间做一个大系统，日平均ip上10万，resin的压力非常的大，除了对程序做优化以外，resin 的优化也小不了。 一、优化配置 修改 conf/resin.conf 文章中的 ＪＶＭ参数 <jvm-arg>-Xms512m</jvm-arg><jvm-arg>-Xss128k</jvm-arg><jvm-arg>-Xmn184m</jvm-arg><jvm-arg>-XX:ParallelGCThreads=20</jvm-arg><jvm-arg>-XX:+UseConcMarkSweepGC</jvm-arg><jvm-arg>-XX:+UseParNewGC</jvm-arg><jvm-arg>-Xdebug</jvm-arg><jvm-arg>-Xloggc:gc.log</jvm-arg> 修改 最大thread-max为2500 <!– Maximum number of threads. –> <thread-max>2500</thread-max> <!– Configures the socket timeout –> <socket-timeout>65s</socket-timeout> <!– Configures the keepalive –> <keepalive-max>10240</keepalive-max> <keepalive-timeout>30s</keepalive-timeout> 二、利用resin-admin监控resin运行情况。 第一行是Thread pool情况，如果发现Peak大于thread max，就应该修改conf/resin.conf 中的thread-max，相应的增大thread-max。 第二行是Threads，如果长期出现在这里而又不是ＳＵＮ的方法，或者resin的方法的话，就要对这些方法进行测试、优化。
JVM调优总结 -Xms -Xmx -Xmn -Xss
三、常见配置举例 堆大小设置JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。典型设置： java -Xmx3550m -Xms3550m -Xmn2g -Xss128k–Xmx3550m：设置JVM最大可用内存为3550M。-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。-Xmn2g：设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。 java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6-XX:MaxPermSize=16m:设置持久代大小为16m。-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。 回收器选择JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。 吞吐量优先的并行收集器如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等。典型配置： java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。 java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。 java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。 java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。 […]
JVM详解之Java垃圾回收机制详解和调优
1.JVM的gc概述 gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。不过常用的jvm都有gc，而且大多数gc都使用类似的算法管理内存和执行收集操作。 在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和jvm支持的垃圾收集算法，便可以进行优化配置垃圾收集器。 垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。 1.1.引用计数 引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，jvm必须适当增减引用数。当某对象的引用数为0时，便可以进行垃圾收集。 1.2.对象引用遍历 早期的jvm使用引用计数，现在大多数jvm采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。 下一步，gc要删除不可到达的对象。删除时，有些gc只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除（sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。 为此，gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有gc运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的 gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作，有的则采用多线程以增加效率。2.几种垃圾回收机制 2.1.标记－清除收集器 这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。 2.2.标记－压缩收集器 有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。 2.3.复制收集器 这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，jvm生成的新对象则放在另一半空间中。gc运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。 2.4.增量收集器 增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。 2.5.分代收集器 这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。jvm生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。 2.6.并发收集器 并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时）一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。 2.7.并行收集器 并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。 3.Sun HotSpot 1.4.1 JVM堆大小的调整 Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。 下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。 下面的命令是把初始大小设置为128M： java –Xms128m –Xmx256m为控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。 下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：java –Xms128m –Xmx128m–XX:NewRatio =3可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。 下面的命令把新域的初始值和最大值设置成64m:java –Xms256m –Xmx256m –Xmn64m 永久域默认大小为4m。运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。 使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免调整，可使用-XX:PerSize标志设置初始值。 下面把永久域初始值设置成32m，最大值设置成64m。java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m 默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden 充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio 可控制新域子空间的大小。 同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRation =2 如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以立即把它们移进旧域，避免在救助空间反复复制。但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX:TargetSurvivorRatio控制救助空间的比例（该值是设置救助空间的使用比例。如救助空间位1M，该值50表示可用500K）。该值是一个百分比，默认值是50。当较大的堆栈使用较低的 sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX:maxtenuring threshold可控制上限。 为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0。设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝50000 …4.BEA JRockit JVM的使用 Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是 Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台（只能适用于使用Jrockit才能使用jrockit81sp1_141_03自带的console监控一些cpu及 memory参数）或者WebLogic Server控制台。 Bea JRockit JVM支持4种垃圾收集器： 4.1.1.分代复制收集器 它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery。这种收集器最适合单cpu机上小型堆操作。 4.1.2.单空间并发收集器 该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。 分代并发收集器这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。 4.1.3.并行收集器 该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。 默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc:，对应四个收集器分别为 gencopy，singlecon，gencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用- Xns:java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m…尽管JRockit支持-verbose:gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、 load和codegen的输出。 注意 ：如果 使用JRockit JVM的话还可以使用WLS自带的console（C:\bea\jrockit81sp1_141_03\bin下）来监控一些数据，如cpu， […]
Resin 3 pro高并发,响应性与稳定性方案
以下方案我是在Intel xeon(至强) 3.2G 2个双核物理CPU+2G内存(Ecc)上进行：resin版本为resin-pro-3.0.21，JVM为Jrockit 1.5_06， resin java 启动参数 -Xms256m -Xmx512m1. 以下为resin.conf配置<!– – Resin 3.0 configuration file. –> <resin xmlns=“http://caucho.com/ns/resin” xmlns:resin=“http://caucho.com/ns/resin/core”> <!– – Logging configuration for the JDK logging API. –> <log name=“” level=“all” path=“stdout:” timestamp=“[%H:%M:%S.%s] “/> <logger name=“com.caucho.java” level=“config”/> <logger name=“com.caucho.loader” level=“config”/> <dependency-check-interval>600s</dependency-check-interval> <javac compiler=“internal” args=“”/> <thread-pool> <thread-max>10240</thread-max> <spare-thread-min>50</spare-thread-min> </thread-pool> <min-free-memory>5M</min-free-memory> <server> <class-loader> <tree-loader path=“${resin.home}/lib”/> […]
破解resin-pro-3.1
在网上查看了很多关于resin性能的文章，比较公认的说法是resin比tomcat的性能要高很多。 但最近在csdn上看了一篇文章，说resin 3.x的免费版与tomcat性能已经不相上下了。原因有两个: 1、tomcat从5.0后就开始在性能上不断改进，以达到生产环境的要求； 2、resin从3.0开始分为免费版与pro版，更多的性能改进被放到了pro版中了，所以免费版的性能就下降了。 基于这样的一些原因，更由于resin的pro版支持session持久化存储、负载均衡及cache等高端特性，于是对破解resin pro版产生了兴趣。 经过N个夜晚的奋战，终于把这个pro版给破解了。 网上也有人说破解得不好的resin pro版可能会使性能下降，个人感觉不存在这样的问题，只要破解了即可享用pro版的各种特性，性能也有大幅提高。 以下的resin启动的部分输出： Resin Professional 3.1.4 (built Tue, 04 Dec 2007 11:27:12 PST)Copyright(c) 1998-2007 Caucho Technology. All rights reserved. Starting Resin on Mon, 31 Dec 2007 17:18:52 +0800 (CST) [17:18:53.640] {main} Proxy Cache disk-size=1024M memory-size=64M[17:18:53.656] {main} PingThread[] starting, checking [][17:18:54.109] {main}[17:18:54.234] {main} Windows XP 5.1 x86[17:18:54.343] {main} […]
使用ping功能使resin更健壮
由于种种原因，resin有时会遇到resin down机的情况，比如：java.lang.OutOfMemoryError。这样的问题如果从代码角度来解决问题，也不是一时半会能解决的，应急解决方案是启用resin-pro的ping功能。 <resin:if test=”${isResinProfessional}”> <ping> <url>http://localhost:8080/ping.jsp</url> <sleep-time>1m</sleep-time> <try-count>5</try-count> <socket-timeout>30s</socket-timeout> </ping> </resin:if> ping.jsp可随意写一些代码，纯html代码也行，只能服务器能响应返回200。 如果访问resin访问http://localhost:8080/ping.jsp返回不是200 code，然后再重试try-count次，如果依然不响应200，则将自动重启resin服务。 如果在resin tag下配置了: <system-property mail.smtp.host=”127.0.0.1″/> <system-property mail.smtp.port=”25″/> 还可以让resin自动给你发个邮件通知你它自动重启过了： <ping resin:type=”com.caucho.server.admin.PingMailer”> <url>http://localhost:8080/ping.jsp</url> <mail-to>[email protected]</mail-to> <mail-from>[email protected]</mail-from> <mail-subject>Resin ping has failed for server ${’${’}server.name}</mail-subject> </ping> 这样配置好了，不管resin出现什么故障，只要resin进程不死，就可以放心睡大觉了。 如果还启用了resin的session持久化存储，用户基本感觉不到服务已经重启过了。 如果启用了resin的cluster，那么请修改httpd.sh，将-server参数加上，不然重启resin后是没有cluster的。
resin服务器突然变慢问题解决办法.
本人负责的一个网站不知道为什么，由周一开始，突然间变得很慢，有时则很快．搞来搞去，搞了差不多一个星期（部份时间开发新功能去了）．终于找到原因了． 服务器情况： linux as4 Intel(R) Xeon(R) CPU 5130 @ 2.00GHz 4G内存， ３００Ｇscsi＋３２０ＧＳＡＴＡ硬盘． resin 3.0.23+ lighttpd resin启动参数 -server -verbose:gc -Xdebug -Xloggc:gc.log -Djava.awt.headless=true -XX:PermSize=128M -XX:NewRatio=4 -XX:+UseConcMarkSweepGC -XX:MaxPermSize=200m -XX:NewSize=100 -XX:MaxNewSize=128m -Xmn256m -Xms512m -Xmx512m 服务器运行一直很正常，到了周一，网站变慢，ＣＰＵ占用５０％以上，但内存点使用５０％,其中大部分是mysql用去了．load average: 10.02, 10.03, 10.00 ． 全部程序都测试过．底层代码也查过．ＪＤＫ换过，ＲＥＳＩＮ版本换过，mysql配置也换过．问题依然存在． 利用resin-admin查看情况． Total memory: 501.44Meg Free memory: 350.37Meg 看上去也正常．不过free memory 变化的很快，由100多M，突然变到300多M．一开始还以为是程序释放了内存．就不去管他了． […]