在生產上部署專案的時候，很多時候遇到這種情況，執行緒開的很多，
但是處理效率卻不是很快，一些引擎服務，作為服務端需要處理的併發服務量很多，
這時候我們開的執行緒數往往就遠大於我們的併發數，最初目標可能就是為了處理大的併發量，
但是這樣有時候造成的每筆交易量的處理時間很慢，百思不得其解是為什麼，也找不到什麼好的答案，
最後我總結並和同時討論之後覺得的原因可能是，cup執行緒切換時消耗時間隨則執行緒數的增大而越來越大，cpu把更多的時間花在的執行緒服務的切換上了，cpu處理正常邏輯需要等待的時間就越久，從效率上講降低了處理業務的速度。
之前一直覺得多執行緒就是高效率（當然在一定的執行緒量內確實可以高效率），但是多執行緒本身並不能提高cpu效率，多執行緒是在資源足夠的情況下利用空閒的資源做需要等待業務的併發處理。這種高效率的情況適用於當前業務處理的消耗的伺服器資源並不充分的情況下，如果當伺服器的資源（cpu、執行記憶體。。）都已經達到上限的情況下，在多開執行緒也因該無法提高其執行效率了。
關於併發可見性的一點理解
我們從上面的圖中可以看到intel core i7 中有4核，每乙個核心中都有獨立的l1 l2 快取記憶體，四個核心共享l3快取記憶體。假設l1 l2快取記憶體在資料寫的時候採用的是寫回的策略，簡單來說就是僅僅更新快取記憶體中的資料，這有在根據替換策略這條資料將要被新資料替換的時候才寫回到更低層次的...
關於php 高併發解決的一點思路
涉及搶購 秒殺 搶票等活動時，為了避免超賣,那麼庫存數量是有限的，但是如果同時下單人數超過了庫存數量，就會導致商品超賣問題。那麼我們怎麼來解決這個問題呢，我的思路如下 偽 sql1 查詢商品庫存 if 庫存數量 0 當沒有併發時，上面的流程看起來是再正常不過了，假設同時兩個人下單，而庫存只有1個了，...
關於php高併發解決的一點思路
涉及搶購 秒殺 搶票等活動時，為了避免超賣，那麼庫存數量是有限的，但是如果同時下單人數超過了庫存數量，就會導致商品超賣問題。那麼我們怎麼來解決這個問題呢，我的思路如下 偽 sql1 查詢商品庫存 if 庫存數量 0 當沒有併發時，上面的流程看起來是再正常不過了，假設同時兩個人下單，而庫存只有1個了，...