說明測試環境
測試介面專案
用jmeter做壓測壓測
結論（暫無）
說明上個月跳槽到了現在的公司，這裡的架構師推薦的乙個做法讓我新奇又懷疑：用斷言來做業務邏輯的判斷。
這位架構師的說法是這樣的：我們的系統有2種異常，系統異常和業務異常。比如登入操作，如果密碼不對，那就是密碼不對異常！
斷言拋異常我們一般都只用來做測試，用來做業務我還真沒想過。
這樣做的好處就是**會變得很簡潔，因為只處理我們認為成功的情況！所有不成功的情況，抓住了就拋異常！
當時我問這樣做對效能會不會有影響，架構師的回答是不會！原因是api介面服務，首先對單個請求速度的影響在毫秒級，對使用者來說幾乎沒沒有任何體驗上的影響；另外對併發量也不會有影響，因為請求是多執行緒的！
但是我問有沒有做壓測時，他們也沒有做！那我只好自己試下咯！
測試環境
測試介面專案
放到github上了：
就是乙個很簡單的模擬登陸的介面，沒有用到資料庫什麼的，就是直接判斷傳入的登入名和密碼是不是指定的乙個值而已。
用jmeter做壓測壓測
100個執行緒同時呼叫一次的結果：
正常登入測試結果（沒拋異常的情況）：
異常登入結果（拋異常的情況）：
1000個執行緒同時呼叫一次的結果（測試3次取中間成績的）：
正常登入測試結果（沒拋異常的情況）：
異常登入結果（拋異常的情況）：
2000個執行緒同時呼叫一次的結果（測試3次取中間成績的）：[本來想測10000的，但是我這伺服器不行超時太多了，2000都超時很多了！]
正常登入測試結果（沒拋異常的情況）：
異常登入結果（拋異常的情況）：
結論可以看出來，當併發量大的時候還是會有比較明顯的影響的。當然如果機器好一些，或者做了集群會好些，但在更高的併發量它還是會有明顯的影響！畢竟我們的電腦沒有無限的資源，併發量上去了總是會發生沒有資源了要等待其他任務釋放資源的情況，而拋異常來結束請求的做法會讓請求的結束變慢，哪怕只是一點點最後總會影響併發量！
（以上結論只是我個人的猜測，由於知識有限不一定正確！）
STL 用純函式做判斷式
一 必要的概念 判斷式是返回bool 或者其他可以隱式轉化為bool的東西 判斷式在stl中廣泛使用。標準關聯容器的比較函式是判斷式，判斷式函式常常作為引數傳遞給演算法，比如find if和多種排序演算法。純函式是返回值只依賴於引數的函式。如果f是乙個純函式，x和y是物件，f x,y 的返回值僅當x...
邏輯等價判斷
寫一段程式，測試p和q兩個邏輯表示式是否邏輯相等 用真值表判斷 輸入的邏輯表示式為命題邏輯表示式 輸入的邏輯表示式可以為復合命題，可包含四種聯接詞 與，或，非，條件 編寫 接收兩個命題邏輯表示式。2 分別為每種聯接詞實現其真值運算。3 從左到右計算邏輯表示式，生成真值表，判斷兩個邏輯表示式是否等價 ...
邏輯判斷 小計
這些還是以前筆記上無意中翻看時候看到的，拿出來大家學習一下，不過應該很久了的筆記了，知識嘛不在新舊。1.true 1 2.false 0 3.new string abc abc 4.new string abc abc 簡單地講述一下吧 1.console.log true 1 trueconso...