同步優化模式
鎖模式
多個應用，如應用a，應用b，共享乙個資源，為同步它們對共享資源的訪問，鎖是最常用的方式，如下：
應用a 應用b
lock（share） lock（share）
unlock（share） unlock（share）
通過鎖，確保任何時候只有乙個應用在訪問共享資源；先到先得，後訪問的應用必須等待前面的應用操作完成，釋放鎖之後才能訪問。所以，應用a或應用b都有可能因等待鎖的釋放而延遲。
模擬鎖模式
但鎖的存在會對效能帶來很大的損耗，所以，在對效能要求高的場景，編碼中常常需要避免鎖的使用。下面的**完成同樣的功能，但沒有用到鎖。
應用a 應用b
continue_wait:
if (flagb) wait(); if (flaga) wait();
flaga = 1 flagb = 1
if (flaga)
flaga = 0 flagb = 0
無鎖模式之一
上述**用標誌替代了鎖機制，效能有了一點提高，但無論是應用a，還是應用b，都會「因對方已經占用了資源，自身必須等待（一定時間）」的特徵沒有改變。
在某些場景下，對涉及共享資源的各方（應用a和應用b）可以區別對待，實際上，在某些包含大資料量的業務中，對涉及共享資源各方的要求是不一樣的。比如，大資料量的資料報的接收，解析。一部分應用是可以在來不及處理的情況下丟棄部分資料報的，從統計概率的角度看，這不會影響所承載的業務。
所以，我們可以根據具體的場景做進一步的優化。
應用a 應用b
try_again:
if (flagb) wait(); if (flaga) break or reurn;
flaga = 1 flagb = 1
if (flaga)
flaga = 0 flagb = 0
這種優化的特點是結合具體業務的實際要求，適當忽略和過濾一部分應用（應用b）對共享資源的訪問，以換取整個系統在效能方面的提公升。
無鎖模式之二
顯然，如果根據業務邏輯的設計要求，涉及共享資源訪問的各方對共享資源的訪問都可以適當的忽略和過濾，那麼，前面的模式可以進一步優化為：
應用a 應用b
try_again:
if (flagb) break or return; if (flaga) break or reurn;
flaga = 1 flagb = 1
if (flaga)
flaga = 0 flagb = 0
上述模型中，應用
a或應用
b均假定為單一例項，如果存在多個例項，則相應的標誌應改為原子操作，以確保標誌可以正確賦值。如下：
flagx = 1
改為atomic_add(flagx)
flagx = 0
改為atomic_sub(flagx)
時間同步優化方案
時間同步伺服器優化方案 一 當前問題及結構描述 1 主 備2臺時間伺服器，分別和不同官方源同步校正時間 2 暢遊所有伺服器，只和主時間伺服器做同步 3 備時間伺服器，作用是提供主時間伺服器內網校正和比對監控，當主備差異時間超過30秒，會預警 但備時間伺服器不提供熱切換功能 4 本次問題根本原因 主時...
實時同步資料優化
需求 每小時同步一次資料，一天最多答十幾萬條。由於剛進公司不久，小白只會php，所以第一時間會考慮用php實現，每次都是先truncate table 在插入表。php初次實現 獲取所有的表名 根據表名獲取資料 一條一條插入資料 一條一條 下面是獲取所有的資料後進行插入 插入乙個資料庫的資料道 ga...
執行緒同步優化例項
如下 package com.bohai.thread public class threadnosynchronized class sharedata class threaddemo extends thread 宣告，並實現threaddemo 構造方法 宣告，並實現threaddemo 帶...