锘??xml version="1.0" encoding="utf-8" standalone="yes"?> 閫氳繃Profiling宸ュ叿鐪嬬粨鏋滐細
1銆?for (int i=0;i<a.size();i++) {
2銆?for (int i=0,n=a.size();i<n;i++) {
甯︾潃鐐規鐤戞垜鍋氫簡涓涓嬭瘯楠岋紝鐨勭‘鏄柟娉?蹇竴鐐圭殑錛屼及璁℃槸a.size()鏂規硶閲岄潰鑺辮垂浜嗕竴鐐瑰浣欑殑鏃墮棿銆傚悗鏉ユ垜鎯沖埌jdk 1.5寮濮嬭繕鏈変竴縐嶉亶鍘嗙殑for/each鏂規硶錛屾垜鍋氫簡涓涓嬫瘮杈冿紝緇撴灉鏈夌偣鎯婅銆?BR>
婧愮▼搴忓涓?BR>
import java.util.ArrayList;
2
3public class ProfileArrayList
{
4
5 public static void main(String[] args)
{
6 ArrayList<String> s=new ArrayList<String>();
7 for (int i=0;i<15000;i++)
{
8 s.add(""+System.currentTimeMillis());
9 }
10 System.out.println("Start ");
11 testOne(s);
12 testTwo(s);
13 testThree(s);
14 System.out.println("End ");
15 }
16
17 private static void testOne(ArrayList<String> a)
{
18 int j=0;String s=null;
19 for (int i=0;i<a.size();i++)
{
20 s=a.get(i);
21 j++;
22 }
23 }
24
25private static void testTwo(ArrayList<String> a)
{
26 int j=0;
27 String s=null;
28 for (int i=0,n=a.size();i<n;i++)
{
29 s=a.get(i);
30 j++;
31 }
32 }
33
34private static void testThree(ArrayList<String> a)
{
35 int j=0;
36 for (String s : a)
{
37 j++;
38 }
39}
40
41}
42
鏂規硶 榪愯鏃墮棿
testOne 0.055764
testTwo 0.043821
testThres 0.132451
涔熷氨鏄錛宩dk 1.5鐨刦or/each寰幆鏄渶鎱㈢殑銆傛湁鐐逛笉鐩鎬俊銆傚紑澶磋寰楁槸鍥犱負璧嬪奸犳垚鐨勶紝浣嗗悗鏉ュ湪鍙︿袱涓柟娉曢噷闈㈠姞涓婅祴鍊艱鍙ワ紝渚濈劧鏄痜or/each鏈鎱€傛瘮杈冩湁瓚g殑緇撴灉銆?BR>
浠庝唬鐮佹竻鏅拌搴︼紝鐢╢or/each娑堣楀涓鐐圭偣鏃墮棿浼間箮涔熸棤鎵璋撱備絾鏄紝鍙︿袱縐嶄唬鐮佷篃涓嶈寰椻滀笉娓呮櫚鈥濓紝鍛靛懙銆傜湅鐫鍔炰簡銆?/P>
欏圭洰鍦板潃錛歨ttp://jakarta.apache.org/jmeter
浣跨敤錛?榪愯bin鐩綍涓嬬殑jmeterw.bat錛岃繍琛宩meter.bat涔熷彲浠ワ紝涓嶈繃灝變細鏈変竴涓懡浠ょ獥鍙f樉紺恒?BR>
瑕佹彁閱掍竴涓嬬殑鏄痡meter鏍規嵁褰撳墠緋葷粺鐨刲ocale鏄劇ず鑿滃崟鐨勮璦錛屼負浜嗘柟渚挎兂璁劇疆鍥炶嫳鏂囩殑璇濓紝鍙互淇敼jmeter.properties鏂囦歡錛岃緗甽anguage=en 錛堟垜涓嬭澆鐨?.1.1鐗堟湰鎶娾滈鍑衡濊璇戜負鈥滄帹鍑衡濓紝鎬庝箞鐪嬮兘涓嶉『鐪?錛?BR>
浣跨敤錛?BR>
JMeter鐨勬祴璇曡鍒掞紙Test Plan錛夊憟鏍戠姸緇撴瀯錛屾爲閲岄潰鏈夊縐嶅厓绱犵被鍨嬶紝鏍戠姸緇撴瀯鐨勫厓绱犱箣闂存湁鐨勬槸鏈夌戶鎵垮叧緋葷殑錛堝叾鍘熺悊鏈夌偣綾諱技log4j錛夈備笅闈㈢畝榪頒竴涓嬪厓绱犵被鍨嬶細
1銆?STRONG>ThreadGroup
欏懼悕鎬濅箟灝辨槸綰跨▼緇勶紝嫻嬭瘯蹇呴』鏈変竴涓猅hreadGroup鍏冪礌浣滀負鍩虹錛堝惁鍒欏氨娌℃湁嫻嬭瘯綰跨▼鍦ㄨ窇浜嗭級錛岃繖涓厓绱犲彲浠ラ厤緗窇澶氬皯涓嚎紼嬨佹瘡涓嚎紼嬪驚鐜灝戞錛屾墍鏈夌嚎紼嬫暟鐨勬誨惎鍔ㄦ椂闂達紙Ramp-up period錛夌瓑絳夈?BR>
2銆?STRONG>Controller
鍖呮嫭Logical Controller鍜孲ampler錛屽墠鑰呯敤鏉ヤ綔涓浜涢昏緫涓婄殑鎺у埗錛屼緥濡傝疆鎹€佹潯浠躲佸驚鐜瓑絳夈係ampler灝辨槸鐪熸鈥滃共媧燴濈殑鈥滃彇鏍峰櫒鈥濓紝渚嬪鈥淗TTP Request鈥濓紝灝辨槸鎷挎潵鎵ц涓涓狧TTP璇鋒眰鐨勩?BR>
3銆?STRONG>Listener
Listener瀵硅姹傝繃紼嬭繘琛岀洃鍚紝鍙互綆鍗曠悊瑙d負鑾峰彇緇撴灉鐨勪笢涓溿備緥濡係imple Data Writer錛屽彲浠ユ妸緇撴灉鍐欏埌涓涓枃鏈枃浠墮噷錛堝叾瀹炴墍鏈塋istener閮藉彲浠ュ啓鏁版嵁鍒版枃浠墮噷錛夛紝榪樻湁View Results in Table錛屽氨鏄妸緇撴灉鏄劇ず鍦ㄨ〃鏍奸噷銆?BR>
4銆?Timer
鐢ㄦ潵鎺у埗鎵ц嫻佺▼涓殑鏃墮棿寤惰繜絳夊姛鑳姐?BR>
5銆?Assertion
鏂█錛屽姞鍒癝ampler閲岄潰鍙互瀵硅繑鍥炵殑緇撴灉榪涜鍒ゆ柇錛屼緥濡傚垽鏂璈TTP榪斿洖緇撴灉閲岄潰鏄惁鍚湁鏌愪釜瀛楃涓層傚鏋滄柇璦涓虹湡錛孞Meter浼氭爣璁拌姹備負鎴愬姛錛屽惁鍒欐爣璁頒負澶辮觸銆?BR>
6銆?Configuration Element
閰嶇疆鐢ㄧ殑鍏冪礌錛屽緢鏈夌敤銆傜敱浜庢祴璇曡鍒掓槸鏍戠姸鍜屾湁緇ф壙鍏崇郴鐨勶紝鍙互鍦ㄩ珮灞傛鎸囧畾涓涓狢onfiguration Element錛屼綆灞傛鐨勭浉鍏砈ampler濡傛灉娌℃湁鏄懼紡鍦版寚瀹氶厤緗紝灝辯戶鎵塊珮灞傛鐨勯厤緗俊鎭傦紙璺焞og4j寰堝儚鍚э紵錛?BR>
7銆?Pre-Processor/Post-Processor Elements
鐢ㄦ潵鍦⊿ampler榪愯鍓嶅拰榪愯鍚庝綔涓浜涢澶勭悊鍜屽悗澶勭悊宸ヤ綔鐨勩備緥濡傚姩鎬佷慨鏀硅姹傜殑鍙傛暟錛堥澶勭悊錛夛紝浠庤繑鍥炰俊鎭噷闈㈡彁鍙栦俊鎭紙鍚庡鐞嗭級絳夌瓑銆?BR>
涓句緥錛氳鍋氫竴涓渶綆鍗曠殑HTTP鍘嬪姏嫻嬭瘯錛?鐢?0涓嚎紼嬭闂竴涓猆RL錛屾瘡涓嚎紼嬭闂?00嬈°?BR>鍋氭硶錛?BR>1銆?鍦═est Plan涓嬮潰鍔犱竴涓猅hread Group錛岄厤緗噷闈紝綰跨▼鏁板~10錛屽驚鐜鏁板~100
2銆?鍦═hread Group涓嬮潰鍔犱竴涓狧TTP Request錛岃繖鏄竴涓猄ampler錛屽湪瀹冪殑閰嶇疆閲岄潰濉啓涓繪満淇℃伅錛岀鍙c佸崗璁佽礬寰勩佸弬鏁扮瓑淇℃伅
3銆?鍦℉TTP Request涓嬮潰鍔犱竴涓猇iew Results in Table錛屽鏋滀綘鎯蟲妸璁板綍璁板埌鏂囦歡錛屽垯濉啓鏂囦歡璺緞銆?BR>4銆?淇濆瓨涓浜涜繖涓猅est Plan錛屽氨鍙互閫夋嫨Run鑿滃崟涓嬮潰鐨凴un鏉ヨ繍琛屼簡銆傜洿鍒癛un鑿滃崟欏逛粠鐏拌壊鍙樺洖榛戣壊錛屽氨琛ㄧず榪愯瀹屼簡銆傚湪View Results in Table涓嬮潰錛屼綘鍙互鐪嬪埌榪愯緇撴灉銆?BR>
鍏充簬鍏冪礌鐨勮緇嗘弿榪板彲浠ュ弬鑰?A >瀹樻柟鏂囨。銆?BR>
JMeter鍔熻兘寰堜赴瀵岀殑錛岃繕鏈夊緢寮虹殑鎵╁睍鑳藉姏錛岃屼笖鍙堟槸鍏嶈垂錛屽煎緱鐮旂┒浣跨敤銆?/FONT>
TPTP鏄痚clipse瀹樻柟鐨刾rofiling鎻掍歡錛屽垵姝ヤ嬌鐢ㄤ笅鎰熻鍔熻兘寮哄ぇ銆?BR>
涓嬭澆瀹夎錛?鍦?A >http://www.eclipse.org/tptp/涓嬭澆錛屾垜閫夋嫨All錛峈untime錛岀劧鍚庡儚鍏跺畠鎻掍歡涓鏍瘋В鍘嬪埌eclipse鐨勭洰褰曪紝鐒跺悗鍏佽eclipse -clean鏉ュ埛鏂頒竴鎶娿?BR>
浣跨敤錛?nbsp;
甯哥敤鐨刾rofiling綆鍗曟潵璁插氨瀵圭▼搴忚繍琛岃繘琛岃褰曪紝鐒跺悗浠庢暟鎹腑鍒嗘瀽鍝簺鏂規硶榪愯鏃墮棿闀匡紝鍝簺瀵硅薄鍚冨唴瀛樺錛屽摢浜涚被鐨勫疄渚嬪絳夌瓑銆備竴涓瘮杈冨ソ鐨勪嬌鐢ㄥ叆闂╯ample鍦ㄨ繖閲岋細 http://www.eclipse.org/tptp/home/documents/tutorials/profilingtool/profilingexample_32.html 鎴戝氨涓嶇綏鍡︿簡銆?BR>
鍊煎緱澶氳鐨勬槸Remote Profiling錛屽氨鏄繙紼嬪墫鏋愩傚疄鐜扮殑鍘熺悊鏄湪榪滅▼鏈哄櫒涓婅繍琛屼竴涓唬鐞嗚繘紼嬶紝瑕佽榪滅▼鍓栨瀽鐨勭▼搴忔垨鑰匒pplication Server鍚姩鐨勬椂鍊欏姞涓涓狫VM鍙傛暟鏉ヨ瘑鍒繖涓唬鐞嗚繘紼嬶紝涓よ呯浉浜掍綔鐢紝浠g悊灝卞彲浠ユ妸鏀墮泦鍒扮殑淇℃伅鍙戠粰鍦ㄨ繙紼嬬殑涓鏂癸紙灝辨槸榪愯鐫eclipse鐨勪竴鏂癸級銆?BR>
鍥犳瑕佸疄鐜癛emote Profiling錛岃繕瑕佸湪鐩爣鏈哄櫒涓婅涓涓猘gent銆?-->
涓嬭澆瀹夎錛?A >http://www.eclipse.org/tptp/home/downloads/drops/TPTP-4.0.1.html銆閫夋嫨瀵瑰簲鎿嶄綔緋葷粺鐨?FONT color=#000000>Agent Controller涓嬭澆錛岄夋嫨Runtime鍗沖彲銆?BR>
涓嬭澆鍚庯紝闃呰渚濈収getting_started.html鐨勮鏄庢潵瀹夎鍗沖彲錛岃繖閲岀畝榪頒竴涓嬶細
1銆?鎶婂畠鐨刡in鐩綍鏀懼埌PATH閲岄潰
2銆?榪愯涓涓婼etConfig鏉ヨ緗弬鏁幫紝娉ㄦ剰濡傛灉鎯寵闄ゆ湰鍦發ocalhost鎰忓鎵浠ユ満鍣ㄩ兘璁塊棶鐨勮瘽錛岃娉ㄦ剰璁劇疆Network Access Mode錛岄粯璁ゆ槸localhost鐨勩?BR>3銆?榪愯RAStart鏉ュ惎鍔ㄤ唬鐞嗭紙Linux涓嬶級
4銆?鏈嶅姟鍣ㄧ紼嬪簭錛堜緥濡倀omcat錛夊惎鍔ㄧ殑JVM鍙傛暟閲岄潰鍔犲叆-XrunpiAgent:server=enabled鍗沖彲錛堣繕鏈夊叾瀹冨弬鏁板煎弬瑙佹枃妗o級
5銆?鐒跺悗灝卞彲浠ュ湪榪滅▼鐢╡clipse鏉ュ惎鍔ㄤ竴涓狿rofiling榪涚▼鏉ttach鍒拌繖涓猘gent controller浜嗐傛晥鏋滃拰鍦╡clipse閲岄潰鐩存帴profile搴旂敤紼嬪簭涓鏍楓?BR>
Sometimes, it seems excessive to pay the cost of synchronization just to read or write an instance field or two. After all, what can go wrong? Unfortunately, with modern processors and compilers, there is plenty of room for error:
Computers with multiple processors can temporarily hold memory values in registers or local memory caches. As a consequence, threads running in different processors may see different values for the same memory location!
Compilers can reorder instructions for maximum throughput. Compilers won't choose an ordering that changes the meaning of the code, but they make the assumption that memory values are only changed when there are explicit instructions in the code. However, a memory value can be changed by another thread!
If you use locks to protect code that can be accessed by multiple threads, then you won't have these problems. Compilers are required to respect locks by flushing local caches as necessary and not inappropriately reordering instructions. The details are explained in the Java Memory Model and Thread Specification developed by JSR 133 (see http://www.jcp.org/en/jsr/detail?id=133). Much of the specification is highly complex and technical, but the document also contains a number of clearly explained examples. A more accessible overview article by Brian Goetz is available at http://www-106.ibm.com/developerworks/java/library/j-jtp02244.html.
NOTE
The volatile keyword offers a lock-free mechanism for synchronizing access to an instance field. If you declare a field as volatile, then the compiler and the virtual machine take into account that the field may be concurrently updated by another thread.
For example, suppose an object has a boolean flag done that is set by one thread and queried by another thread. You have two choices:
Use a lock, for example:
public synchronized boolean isDone() { return done; }
private boolean done;
(This approach has a potential drawback: the isDone method can block if another thread has locked the object.)
Declare the field as volatile:
public boolean isDone() { return done; }
private volatile boolean done;
Of course, accessing a volatile variable will be slower than accessing a regular variablethat is the price to pay for thread safety.
NOTE
![]() |
Prior to JDK 5.0, the semantics of volatile were rather permissive. The language designers attempted to give implementors leeway in optimizing the performance of code that uses volatile fields. However, the old specification was so complex that implementors didn't always follow it, and it allowed confusing and undesirable behavior, such as immutable objects that weren't truly immutable. |
In summary, concurrent access to a field is safe in these three conditions:
The field is volatile.
The field is final, and it is accessed after the constructor has completed.
The field access is protected by a lock.