協程java

1. java協程和futuretask的區別

Callable要採用ExecutorSevice的submit方法提交,返回Future對象,通過Future的get()方法,同步拿到線程的返回結果,實例代碼如下:
public class ThreadExample12 { public static void main(String[] args) {
ExecutorService threadPool = Executors.newSingleThreadExecutor();
Future<String> future = threadPool.submit(new Callable<String>() { public String call() throws Exception {
Thread.sleep(2000); return "Hello World";
};
});

System.out.println("等待結果"); try {
System.out.println("返回結果為:" + future.get());
} catch (InterruptedException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
}
}

Future取得的結果類型和Callable返回的結果類型必須一致,這是通過泛型來實現的。Callable要採用ExecutorSevice的submit方法提交,返回的Future對象可以取消任務,通過調用Future的future.cancel(true)方法實現,Future對象還可以對超時線程進行關閉,通過future.wait(3);如果線程耗時超過3秒則拋出異常
在這里有人可能會有疑問,既然要同步返回結果,那我為什麼要再開一個線程去執行呢,還不如直接在主線程執行就好。但是這種是局限於在一個線程時,如果需要同時執行多個線程,等待多個線程返回結果時,在主線程中是不能實現這種功能的。可以看一下實例代碼,就能明白了:
public class ThreadExample13 { public static void main(String[] args) {
ExecutorService threadPool = Executors.newFixedThreadPool(10);
CompletionService<Integer> completionService = new ExecutorCompletionService<Integer>(threadPool); for (int i = 1; i <= 10; i++) {
final int seq = i;
completionService.submit(new Callable<Integer>() {
@Override public Integer call() throws Exception {
Thread.sleep(new Random().nextInt(5000)); return seq;
}
});
} for (int i = 0; i < 10; i++) { try {
System.out.println(completionService.take().get());
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}
}
}
}

2. 計算機專業學python還是學習java，哪個好就業

無論是選擇Java還是Python，其實只要能學好，都可以找到不錯的崗位工作。
如果說非要推薦就業，就目前的市場發展情況，建議選擇Java。
因為項目保有量大，從業人員也多。
項目保有量大，也就意味著升級和二期，也需要Java程序員。
從業人員多，也就意味著企業在技術選型方面也會更側重與Java。 好招人。

3. VR需要掌握什麼編程語言

VR需要掌握的編程語言如下：C#，C++語言，Java，其他計算機圖形學與GPU編程。

1、C#

C#基礎語法與演算法、面向對象編程、C#是數據結構與高級語法；是做U3D的基礎語言。而Unity 把 C# 當作腳本語言使用。Unity3D引擎結構與物理結構、UGUI與動畫系統、導航系統，數據存儲，資料庫，協程，WWW類、網路，資源管理，特效系統，性能優化。

2、 C++語言

Unreal 引擎同樣使用 C++ 進行開發。MiddleVR 提供了基於 C++ 的SDK。

(3)協程java擴展閱讀：

VR的應用

1、在影視娛樂中的應用

近年來，由於虛擬現實技術在影視業的廣泛應用，以虛擬現實技術為主而建立的第一現場9DVR體驗館得以實現。第一現場9DVR體驗館自建成以來，在影視娛樂市場中的影響力非常大，此體驗館可以讓觀影者體會到置身於真實場景之中的感覺，讓體驗者沉浸在影片所創造的虛擬環境之中。

2、在教育中的應用

如今，虛擬現實技術已經成為促進教育發展的一種新型教育手段。傳統的教育只是一味地給學生灌輸知識，而現在利用虛擬現實技術可以幫助學生打造生動、逼真的學習環境，使學生通過真實感受來增強記憶。

相比於被動性灌輸，利用虛擬現實技術來進行自主學習更容易讓學生接受，這種方式更容易激發學生的學習興趣。此外，各大院校利用虛擬現實技術還建立了與學科相關的虛擬實驗室來幫助學生更好的學習。

3、在設計領域的應用

虛擬現實技術在設計領域小有成就，例如室內設計，人們可以利用虛擬現實技術把室內結構、房屋外形通過虛擬技術表現出來，使之變成可以看得見的物體和環境。

同時，在設計初期，設計師可以將自己的想法通過虛擬現實技術模擬出來，可以在虛擬環境中預先看到室內的實際效果，這樣既節省了時間，又降低了成本。

4. golang 協程什麼時候切換

應puppet大拿劉宇的邀請，我去西山居運維團隊做了一個簡短分享，談談為什麼我要將我們的項目從python轉向go。

坦白的講，在一幫python用戶面前講為什麼放棄python轉而用go其實是一件壓力蠻大的事情，語言之爭就跟vim和emacs之爭一樣，是一個永恆的無解話題，稍微不注意就可能導致粉絲強烈地反擊。所以我只會從我們項目實際情況出發，來講講為什麼我最終選擇了go。

為什麼放棄python

首先，我其實得說說為什麼我們會選擇python。在我加入企業快盤團隊之前，整個項目包括更早的金山快盤都是採用python進行開發的。至於為什麼這么選擇，當時的架構師蔥頭告訴我，主要是因為python上手簡單，開發迅速。對於團隊裡面大部分完全沒服務端開發經驗的同學來說，python真的是一個很好的選擇。

python的簡單高效，我是深有體會的。當時私有雲項目也就幾個程序員，但是我們要服務多家大型企業，進行定製化的開發，多虧了python，我們才能快速出活。後來企業快盤掛掉之後，我們啟動輕辦公項目，自然也使用python進行了原始版本的構建。

python雖然很強大，但我們在使用的時候也碰到了一些問題，主要由如下幾個方面：

動態語言

python是一門動態強類型語言。但是，仍然可能出現int + string這樣的運行時錯誤，因為對於一個變數，在寫代碼的時候，我們有時候很容易就忘記這個變數到底是啥類型的了。

在python裡面，可以允許同名函數的出現，後一個函數會覆蓋前一個函數，有一次我們系統一個很嚴重的錯誤就是因為這個導致的。

上面說到的這些，靜態語言在編譯的時候就能幫我們檢測出來，而不需要等到運行時出問題才知道。雖然我們有很完善的測試用例，但總有case遺漏的情況。所以每次出現運行時錯誤，我心裡都想著如果能在編譯的時候就發現該多好。

性能

其實這個一直是很多人吐槽python的地方，但python有它適合乾的事情，硬是要用python進行一些高性能模塊的開發，那也有點難為它了。

python的GIL導致無法真正的多線程，大家可能會說我用多進程不就完了。但如果一些計算需要涉及到多進程交互，進程之間的通訊開銷也是不得不考慮的。

無狀態的分布式處理使用多進程很方便，譬如處理http請求，我們就是在nginx後面掛載了200多個django server來處理http的,但這么多個進程自然導致整體機器負載偏高。

但即使我們使用了多個django進程來處理http請求，對於一些超大量請求，python仍然處理不過來。所以我們使用openresty，將高頻次的http請求使用lua來實現。可這樣又導致使用兩種開發語言，而且一些邏輯還得寫兩份不同的代碼。

同步網路模型

django的網路是同步阻塞的，也就是說，如果我們需要訪問外部的一個服務，在等待結果返回這段時間，django不能處理任何其他的邏輯（當然，多線程的除外）。如果訪問外部服務需要很長時間，那就意味著我們的整個服務幾乎在很長一段時間完全不可用。

為了解決這個問題，我們只能不斷的多開django進程，同時需要保證所有服務都能快速的處理響應，但想想這其實是一件很不靠譜的事情。

非同步網路模型

tornado的網路模型是非同步的，這意味著它不會出現django那樣因為外部服務不可用導致這個服務無法響應的問題。話說，比起django，我可是非常喜歡tornado的，小巧簡單，以前還寫過幾篇深入剖析tornado的文章了。

雖然tornado是非同步的，但是python的mysql庫都不支持非同步，這也就意味著如果我們在tornado裡面訪問資料庫，我們仍然可能面臨因為資料庫問題造成的整個服務不可用。

其實非同步模型最大的問題在於代碼邏輯的割裂，因為是事件觸發的，所以我們都是通過callback進行相關處理，於是代碼裡面就經常出現干一件事情，傳一個callback，然後callback裡面又傳callback的情況，這樣的結果就是整個代碼邏輯非常混亂。

python沒有原生的協程支持，雖然可以通過gevent，greenlet這種的上patch方式來支持協程，但畢竟更改了python源碼。另外，python的yield也可以進行簡單的協程模擬，但畢竟不能跨堆棧，局限性很大，不知道3.x的版本有沒有改進。

開發運維部署

當我第一次使用python開發項目，我是沒成功安裝上項目需要的包的，光安裝成功mysql庫就弄了很久。後來，是一位同事將他整個python目錄打包給我用，我才能正常的將項目跑起來。話說，現在有了docker，是多麼讓人幸福的一件事情。

而部署python服務的時候，我們需要在伺服器上面安裝一堆的包，光是這一點就讓人很麻煩，雖然可以通過puppet，salt這些自動化工具解決部署問題，但相比而言，靜態編譯語言只用扔一個二進制文件，可就方便太多了。

代碼失控

python非常靈活簡單，寫c幾十行代碼才能搞定的功能，python一行代碼沒准就能解決。但是太簡單，反而導致很多同學無法對代碼進行深層次的思考，對整個架構進行細致的考量。來了一個需求，啪啪啪，鍵盤敲完開速實現，結果就是代碼越來越混亂，最終導致了整個項目代碼失控。

雖然這也有我們自身的原因，譬如沒好的代碼review機制，沒有好的項目規范，但個人感覺，如果一個程序員沒經過良好的編碼訓練，用python很容易就寫出爛的代碼，因為太自由了。

當然，我這里並不是說用python無法進行大型項目的開發，豆瓣，dropbox都是很好的例子，只是在我們項目中，我們的python代碼失控了。

上面提到的都是我們在實際項目中使用python遇到的問題，雖然最終都解決了，但是讓我愈發的覺得，隨著項目復雜度的增大，流量性能壓力的增大，python並不是一個很好的選擇。

為什麼選擇go

說完了python，現在來說說為什麼我們選擇go。其實除了python，我們也有其他的選擇，java，php，lua(openresty)，但最終我們選擇了go。

雖然java和php都是最好的編程語言（大家都這么爭的），但我更傾向一門更簡單的語言。而openresty，雖然性能強悍，但lua仍然是動態語言，也會碰到前面說的動態語言一些問題。最後，前金山許式偉用的go，前快盤架構師蔥頭也用的go，所以我們很自然地選擇了go。

go並不是完美，一堆值得我們吐槽的地方。

error，好吧，如果有語言潔癖的同學可能真的受不了go的語法，尤其是約定的最後一個返回值是error。項目裡面經常會充斥這樣的代碼:

if _, err := w.Write(data1); err != nil {
returun err
}
if _, err := w.Write(data2); err != nil {
returun err
}

難怪有個梗是對於一個需求，java的程序員在寫配置的時候，go程序員已經寫了大部分代碼，但是當java的程序員寫完的時候，go程序員還在寫err != nil。

這方面，errors-are-values倒是推薦了一個不錯的解決方案。

包管理，go的包管理太弱了，只有一個go get，也就是如果不小心更新了一個外部庫，很有可能就導致現有的代碼編譯不過了。雖然已經有很多開源方案，譬如godep以及現在才出來的gb等，但畢竟不是官方的。貌似google也是通過vendor機制來管理第三方庫的。希望go 1.5或者之後的版本能好好處理下這個問題。

GC，java的GC發展20年了，go才這么點時間，gc鐵定不完善。所以我們仍然不能隨心所欲的寫代碼，不然在大請求量下面gc可能會卡頓整個服務。所以有時候，該用對象池，內存池的一定要用，雖然代碼丑了點，但好歹性能上去了。

泛型，雖然go有inteface，但泛型的缺失會讓我們在實現一個功能的時候寫大量的重復代碼，譬如int32和int64類型的sort，我們得為分別寫兩套代碼，好冗餘。go 1.4之後有了go generate的支持，但這種的仍然需要自己根據go的AST庫來手動寫相關的parser，難度也挺大的。雖然也有很多開源的generate實現，但畢竟不是官方的。

當然還有很多值得吐槽的地方，就不一一列舉了，但是go仍舊有它的優勢。

靜態語言，強類型。靜態編譯能幫我們檢查出來大量的錯誤，go的強類型甚至變態到不支持隱式的類型轉換。雖然寫代碼感覺很別扭，但減少了犯錯的可能。
gofmt，應該這是我知道的第一個官方提供統一格式化代碼工具的語言了。有了gofmt，大家的代碼長一個樣了，也就沒有花括弧到底放到結尾還是新開一行這種蛋疼的代碼風格討論了。因為大家的代碼風格一樣，所以看go的代碼很容易。
天生的並行支持，因為goroutine以及channel，用go寫分布式應用，寫並發程序異常的容易。沒有了蛋疼的callback導致的代碼邏輯割裂，代碼邏輯都是順序的。
性能，go的性能可能趕不上c，c++以及openresty，但真的也挺強悍的。在我們的項目中，現在單機就部署了一個go的進程，就完全能夠勝任以前200個python進程乾的事情，而且CPU和MEM佔用更低。
運維部署，直接編譯成二進制，扔到伺服器上面就成，比python需要安裝一堆的環境那是簡單的太多了。當然，如果有cgo，我們也需要將對應的動態庫給扔過去。
開發效率，雖然go是靜態語言，但我個人感覺開發效率真的挺高，直覺上面跟python不相上下。對於我個人來說，最好的例子就是我用go快速開發了非常多的開源組件，譬如ledisdb，go-mysql等，而這些最開始的版本都是在很短的時間裡面完成的。對於我們項目來說，我們也是用go在一個月就重構完成了第一個版本，並發布。

實際項目中一些Go Tips

到現在為止，我們幾乎所有的服務端項目都已經轉向go，當然在使用的時候也遇到了一些問題，列出來算是經驗分享吧。

godep，我們使用godep進行第三方庫管理，但是godep我碰到的最大的坑就是build tag問題，如果一個文件有build tag，godep很有可能就會忽略這個文件。
IO deadline，如果能自己在應用層處理的都自己處理，go的deadline內部是timer來控制，但timer內部採用一個array來實現的heap，全局共用一個鎖，如果大並發量，並且timer數量過多，timeout變動太頻繁，很容易就引起性能問題。
GC，這個前面也說了，多用內存池，對象池，另外，我還發現，如果對象的生命周期跟goroutine一致，對性能的提升也不錯，也在go的group問過相關問題，大家猜測可能是因為一些對象其實是在goroutine的8k棧上面分配的，所以一起回收沒有額外GC了。
Go gob，如果要做RPC服務，gob並不是一個很好的選擇，首先就跟python的pickle不通用，然後為了做不同系統的數據傳入，任何包都必須帶上類型的詳細信息，size太大。go裡面現在還沒一套官方的RPC方案，gRPC貌似有上位的可能。

5. 會一點java,有面向對象編程基礎，選擇入門unity有很大難度嗎應如何有效的入門

你可以對照著我們的課程大綱看一下自己的能力

C#語言

數據類型，常量，變數，運算符和表達式及命名規則
輸入輸出方法，數據類型轉換
分支結構，循環，關系運算符，邏輯運算符
一維數組與foreach循環，冒泡排序與二維數組
枚舉與結構體定義、結構體成員及訪問

面向對象編程 類和面向對象概念，對象的欄位成員
對象中的方法成員，方法類型詳解
對象中的屬性和方法參數
string字元串對象、裝箱和拆箱、方法的重載和遞歸
構造和析構函數
抽象方法、虛方法，多態實現
靜抽象類，靜態類和單例設計模式

介面和泛型
集合、委託 介面介紹，介面實現多態
泛型方法、泛型類、泛型約束
ArrayList、List、Queue(隊列）
Stack(堆棧）、Hashtable (哈希表)、Dictionary(字典）
委託與事件、C#反射類、實現範例的Observer設計模式

實戰項目及階段考核 2048、隨機抽獎系統、圖書管理系統、乒乓球大對決
題庫中隨機抽題，包含筆試題、上機題，學生需在規定時間內作答

Unity引擎
開發基礎 Unity面板及基本操作
游戲對象的操作
預制體的創建和使用
3D基礎理論

面向組件開發 Unity工程結構
Unity開發框架
面向組件的開發思想
腳本組件及生命周期、回調方法的概念
常用類（Transform、GameObject、Vector3、
Quaternion、Time、Mathf、Resources資源載入）

物理系統 輸入控制、Input類，輸入配置
碰撞器--Collider組件家族
剛體組件與力--Rigidbody組件
剛體組件與力--Rigidbody組件、碰撞條件及回調方法
物理材質、射線、發射方法及重載、角色控制器

實戰項目 打飛機、坦克大戰、HelixJump、運轉銀河系、打磚塊、接金幣

2D精靈和UI Sprite精靈，圖集的切割、打包，計算機2D圖形學基礎
2D物理組件（剛體、碰撞器）
2D動畫創建--初識Animation
2D開發常用類，碰撞、觸發回調
TimeLine製作劇情

UGUI初級 畫布Canvas初識
UV坐標，UI坐標
基本控制項、復合控制項
UGUI的布局和適配方案

UGUI高級 Canvas的渲染模式、適配模式介紹
水平布局、垂直布局、網格布局組件
ScrollView效果製作、Toggle分頁、QQ聊天窗口
UI多種交互方式、事件回調

UGUI案例 MVC設計模式，小地圖製作、方位坐標、背包、關卡選擇案例

實戰項目 捕魚達人、夢幻西遊、超級瑪麗、消消樂

動畫系統 模型資源分析
動畫類型，Avatar系統
動畫節點、動畫狀態機
原畫UV展開；人形動畫代碼控制，角色控制器綜合應用

動畫系統高級 動畫遮罩；
IK動畫；
動畫事件；
動畫曲線

unity高級

數據持久化 PlayerPrefs、Sqlite
XML、JSON、CSV文檔讀取、Excel加密存取

WWW類和協程 協程、線程和進程的概念
協程的設計思想及使用
WWW類，封裝請求工具類
Http協議簡介（Get、Post）

資源載入 AssetBundle資源打包及依賴分析
基於WWW類遠程資源獲取
使用AssetBundle進行資源載入及內存管理

性能優化 針對CPU、GPU、內存、美術資源的優化方案
對象池技術

FSM 設計模式
FSM案例人物控制
FSM案例-Buffer系統
FSM案例-AI系統

行為樹 游戲AI方案對比，最優解問題分析；
BehaviorDesigner插件，代碼控制

我這有一個Unity學習交流，裡面有大神也有小白，可以在群里甩問題啊，而且不定期分享學習資料 q.u.n.[887.207.898]q.u.n.備註：小白

A*演算法 理解AStar演算法原理；
代碼實現AStar演算法

Shader 圖形學初探，基礎知識；
固定管線著色器；
頂面著色器和表面著色器；
Shader案例

網路 Unet、HLAPI詳解，網路版CS射擊；
基於ASP.net的web站點搭建；
SqlServer資料庫的接入和訪問；
基於Post請求的數據通信；
Socket編程基礎、制定協議、Socket通信、數據安全

實戰項目
及階段考核 陰陽師、鎮魔曲、荒野行動、泡泡堂
題庫中隨機抽題，包含筆試題、上機題，學生需在規定時間內作答

VR、AR

VR-HTC Vive SteamVR SDK接入及分析
SteamVR 預制體和案例分析
手柄、頭部Transform獲取，點擊事件獲取
3D UI交互
射箭、魔法陣繪制、釣線瞬移
性能優化，降低眩暈策略

AR--高通SDK AAR介紹及AR項目展示、常用SDK介紹
Vuforia賬號注冊、識別圖的上傳與製作、數據包的下載及使用
手機觸屏、陀螺儀與發布的講解

項目架構與
項目管理 模塊封裝原理與規范，通用框架搭建，模塊封裝，消息中心、模塊管理器、通信模塊、編輯器擴展工具編寫
熱更新模塊（資源熱更、邏輯熱更）、LuaUI架構、LuaSocket架構、Lua資料庫架構、AssetBundle管理規則、AssetBundle自動打包
團隊合作工具--SVN

綜合項目 學生以小組為單位，組員分工，合作完成至少一個項目，包含但不限於：
RPG角色扮演游戲、ACT動作游戲、AVG冒險游戲、SLG策略游戲、FPS第一人稱射擊游戲、PZL益智類游戲、MSC音樂游戲、虛擬模擬、VR展示、AR游戲； 項目答辯：學員對本團隊的項目進行講解，講師進行考核，模擬企業中技術面試環節對項目進行答辯

項目答辯
及評審 對於完成的項目分組進行答辯，按照功能實現、代碼規范、以及完成度等進行打分

6. 經常聽到進程與線程這是什麼東西

經常聽到程序員講進程、線程、協程，那麼進程、線程、協程是同一種事物嗎？它們之間有什麼區別？

一、關於進程進程？

1、什麼是進程

隨便任何打開一個軟體或文件，它都是一個正在運行的進程，進程就是正在運行中的程序；

創建進程就是在內存中申請一塊獨立的內存空間，將需要運行的代碼放進行執行；所以，一個進行就是一塊獨立的內存空間；

程序就是一堆躺在硬碟上的代碼，是「死的」；而進程則表示程序正在執行的過程，是「活的」；

代碼被運行中就是進程，進程一定是在內存中運行著的。

2、進程的3種狀態

如果一台計算機只能同時運行1個程序，現在打開了程序A，則表示A進程在運行態；

再打開程序B，A進程則被切換到後台，A進程的狀態稱為阻塞態，B進程是阻塞態；

將程序B切換到程序A，在切換的過程中，A進程會迅速從阻塞態切換到准備就緒的就緒態；程序切換成功以後，A進程會變成運行態，B進程則變為阻塞態。

3、父進程與子進程

打開一個進程A，在這個進程中再創建多個新進程B，可以稱為A進程是其他剛剛創建進程B的父進程，新進程B是進程A的子進程。

註：兩個進程之間的數據是互相隔離的，不能直接訪問；進程間通信需要藉助工具進行，比如：隊列、堆棧、管道（subprocess）。

二、關於線程線程？

1、什麼線程

打開一個新的程序，會在系統中開啟一個新的進程，但進程並不負責具體的運行，具體的運行由線程執行；

進程是資源單位，線程是執行單位；

舉例說明：打開一個wps軟體，這個時候並沒有創建新的文件，如果創建了新的文檔，這個文檔就是當下運行的wps軟體的線程；wps軟體本身只佔用資源，並沒有做具體執行操作，新建的文檔才是具體的執行單位

7. python並發和java並發的區別

使用tornado的前提是你的服務是IO密集型的，並且你得寫非同步api，也可以請參考我簽名中的框架，把tornado改造成eventloop+threadpool (GitHub - nikoloss/iceworld: tonado的multi-thread 多線程封裝)。我們公司的android ios wap後台全是這套框架在提供服務。目前已經切換到一個分布式http響應群組裡面了，此時tornado只是作為一個中繼的gateway存在：GitHub - nikoloss/cellnest: 分布式service

在沒有阻塞的情況下，python的性能肯定不如編譯型語言。這種全非同步的模型的優勢也無法體現出來，一旦有IO操作了，這種全非同步模型的第一步accpet新連接的操作並不會暫停，也就是只要有內容抵達，至少ioloop這個環節是可以照單全收的，接收之後協程處理，隨著並發量增長它的性能下降是平穩且平滑的。反觀線程模型，如果消費數據趕不上新連接新數據的生產，性能就會直線下降。

你的700qps差不多，你可以換3.1或者3.2的tornado試試，1100~1400應該可以跑出來。當然追求一個靜態文本的輸出性能是否有必要，我覺得實際情況比這種單純的壓測要復雜的多。

8. 可以在java上實現類似goroutines一樣的協程機制而不修改jvm源碼嗎

操作系統就是用C/C++寫的。 C/C++能夠直接調用系統介面。 你知道Java為什麼要JVM才能跑嗎？因為他不能直接調用系統介面。 所以C/C++不需要虛擬機。 但是因為操作系統的不同，介面調用方式不同。所以C/C++不能跨平台。

9. java游戲伺服器開發有前途嗎

最近剛跳槽，到新公司已經幹了有兩周時間了，這兩周時間是過得比較充實的，因為這家新公司是個小公司，以前以單機開發為主，伺服器方面我一個人，做兩個游戲的伺服器開發工作，當然，一個很簡單，另一個就相對復雜點，簡單的那個是個弱聯網游戲，伺服器只需要做好數據存檔和登錄支付驗證就好了，而另一個，則是相對復雜的slg游戲，我感覺這是又一款cok，而公司目前並不打算再招伺服器了，所以估計這個項目我會一個人干到明年吧，等第一款上線賺錢了，可能會再招伺服器。老實說，面試的時候，我就覺得這份工作對我而言是一個挑戰，而當我清楚的了解了公司狀況之後，我依然決定接受這個挑戰。
說說我之前的經歷吧，大四的時候，學校安排來北京培訓java（培訓沒什麼丟臉的，出來找工作我也用的真學歷真背景，不像某峰互聯），之後我去了培訓機構推薦的公司實習，那個時候，工資2k，然而工作也幹得很開心，跟著前輩學到了不少東西，當時是做微信公眾號開發的，我跟著前輩做微信後台開發，當時使用SpringMVC+MyBatis框架，剛接觸的時候，我自己學了挺久才弄明白，後來弄明白之後想想，其實挺簡單，對於邏輯開發的程序員來說，你只需要弄懂工作流程就好了，頁面怎麼跳轉，跳轉怎麼傳值，數據怎麼處理，這些足夠了，當然我是個不滿足的人，我會去弄明白，為什麼用這個框架、為什麼不用別的、用這個有什麼好處、如果讓我自己來做這個後台、我會怎麼搭建？帶著這些問題，我會試著自己搭建一下後台框架（雖然前期大部分是復制粘貼）。除了框架部分，微信高級介面也是我研究的重點，我會去官方文檔看看微信是怎麼接入的，然後研究研究前輩的代碼是怎麼寫的，所謂的干一行愛一行大概就是這樣吧，當時我覺得，微信開發，是很有前途的，而我們公司用的框架，也是最先進的（後來看來，確實這個框架組合是當前最流行的框架，而當時，微信公眾號也確實是當時互聯網行業的一個風口，微信後來把h5帶起來了，導致現在一個好的h5前端都是供不應求的，薪資很高）。
說了這么多，為什麼後來又轉行做游戲了呢？其實是這樣的，當時在第一家公司，我的上級打算跳槽走了，帶走整個下面的技術，而不帶實習生，有那麼一兩個月，實習生就一直閑著沒事做，對於我來說，這樣過著就太無聊了，我喜歡挑戰，於是我投簡歷，重新找了份實習工作，在一個游戲公司做java伺服器開發，公司挺大的，幾年前憑借一款slg頁游稱霸游戲行業（什麼游戲我就不說了，說了就知道什麼公司了），後來游戲行業往手游發展，這款slg也出了手游版，這一款游戲，幾乎支撐了整個公司，再加上後來出的幾款手游，公司發展挺好的，我所實習的部門做的是一款mmorpg手游，從實習做到了轉正，做了近一年了，然而這款rpg手游的數據卻不是太好，第一次封測次日留存23，第二次26（現在這家公司的游戲能達到80多次日留存），七日就更不用說了，而我也能感覺到，作為一款mmo游戲，玩家之間的交互實在太少，從頭玩下來，我覺得這是一款單機，失去了mmo的本質，在項目組准備進行第三次封測的時候，我選擇了離開，原因很多，不僅僅因為游戲數據不好，也有一些個人原因吧，不過說實話，是這家公司帶我走進了游戲行業，我很感謝，我覺得游戲行業是一個非常有前景的行業，甚至比之前我認為最好的微信開發還要好，游戲行業非常暴利，在這家公司工作就能感受到，策劃文檔中，充滿了挖坑預留的計費點，這一塊可以正常玩兒，但你如果充錢，你就比別人牛逼。網路游戲，最重要的，就是控制好平民玩家跟普通玩家的佔比以及游戲平衡（當意識到公司的游戲如此處心積慮想要坑錢的時候，我突然明白為什麼公司的游戲大多被騰訊代理了，為什麼騰訊控股，原來如此，沒錢玩兒你**，哈哈）。由此也可以看出，游戲的商業化，已經把游戲公司帶入了一個固定的模式——無條件坑錢，我覺得已經失去了游戲的本質，我看過一本書，叫《游戲人生》（當時在cocos2014年開發者大會上買的。覺得挺值的），書已經送人了，但內容我看了一大半，從游戲的產生，到玩家的心理，到為什麼需要游戲，這本書都詮釋的熱別好（我覺得游戲策劃都應該看看這本書，做良心游戲，拒絕一味坑錢）。啊，突然發現這一段說的有點偏了，說到底，我也只是做游戲伺服器開發的，我也改變不了游戲行業，我只要做好我做的。其實大的游戲公司，就應該走這種商業化路線，憑借幾款長生命周期的游戲，支撐公司流水。
從轉行做游戲之後，我倒是覺得，游戲開發比web開發有趣多了，當然技術上也比web難多了，之前發過一篇討論，web開發何和游戲開發的區別，http://gad.qq.com/content/wendetail/7082370，我把我的答案再粘貼一遍（實際上是別人要求我上他的號去回答的，於是我就自己回答了我自己的問題）：
1.從第三方支持來說，web後台有很多成熟的第三方框架，開發者不需要關心底層控制器跳轉的實現，只需要一個或幾個配置文件，就能完成核心控制器的部分，而開發者只需要關注web自身的業務邏輯，將邏輯與框架融合即可，使用框架一方面簡化控制層代碼，一方面很好的實現了業務邏輯的分層。而游戲後台開發中，因為各種游戲的需求差異性很大，從網路層，到業務邏輯層，各方面都必須根據自己游戲需求搭建適合自己的框架，因此很難有一些通用的東西能提煉出來一款成熟的框架，游戲後台開發基本上需要自己搭建適合自己的框架。
2.從業務邏輯層面來說，web後台基本上邏輯都是大同小異的，或許這一套系統，稍微改改，另一套系統就能用，而游戲就不同了，每個游戲都有自己的特色，根據策劃的不同需求而實現不同的邏輯，不過也會有一些通用的模塊，但整體上差異性還是很大的。
3.從數據持久化來說，web的數據基本上是很規整的，表與表之間關系很明確，並且以後也不會有太大的變化，而游戲中的數據多種多樣，隨著開服之後，數據的變化也是多種多樣，甚至傳統的關系型資料庫根本無法滿足游戲數據持久化的需求，游戲中有很多狀態和數據是需要伺服器來保存的，我個人認為，在游戲開發中，nosql比關系型資料庫更實用。
4.從通信層來說，web中的用戶都是一個個獨立的個體，而游戲中是多人在線的一個游戲世界，在這個游戲世界中，玩家與玩家之間需要進行交互，這就需要伺服器實時的向所有在線玩家進行消息廣播，這一點很損耗伺服器性能的，在這方面，游戲後台要比web做更多的處理，游戲伺服器是一個IO密集的伺服器類型。
以上便是我當時的答案，或許我的見解尚淺，畢竟我做游戲不到一年，不過對於後台開發這塊，我還是有一點話語權的，從實習游戲開發開始，我便經歷了一個轉換的過程，幾乎又是一個從零開始的學習過程，從mina框架到protobuffer，這些東西，我相信web開發很少接觸（mina作為網路通信框架，web中幾乎只有http通信，protobuffer作為通信協議，web最多用json，其實二者形式上差別不大，但數據大小千差萬別）。而游戲的邏輯，也是比web復雜得多，不得不說，web後台成熟的第三方框架是做的真的很好。
經歷了上家公司的洗禮，我想我對游戲後台開發有了足夠的了解，於是我找到了我現在這家公司，這家公司目前只有我一個伺服器後台，做兩款游戲，一款是塔防類，准備由單機改成弱聯網，伺服器存檔，並做登錄支付驗證，另一款，是比較龐大的slg手游，是准備帶領公司走上巔峰的項目，說一款slg帶領一個公司走上巔峰一點兒不為過，我上家公司就是這樣的，憑借一款《xxxx》（哈哈，名字不透露），走上人生巔峰。我之所以接受這份工作，是因為我接受挑戰，從底層寫起，從架構寫起，這是作為一年工作經驗的我想都不敢想的，不過這是一個挑戰自我，證明自我的機會，我願意接受這個挑戰，人生總會有很多爬坑的時候，但爬過了坑，就真的是人生巔峰了。我接受這個工作的另一個原因，就是公司發展確實不錯，以前做的單機，都是很火的（雖然我認為我自己一個人也能做，我也是學過cocos的），而現在公司也准確的把握了游戲行業的風口——slg，coc和cok的成功案例就能證明一切，mmorpg也不一定能做起來了，moba倒是有可能，但你要跟lol做不到80%的相似，我估計沒人願意在手機玩兒moba，slg或許是性價比最高的了。這么有挑戰的工作，還要從架構寫起，這樣的挑戰，我喜歡！
說說互聯網業的書吧，我認為這個行業的書，分為兩種，理論型的和技術型的，所謂理論型，就是長篇大論互聯網發展，行業模式等，而技術型，就是類似技術的工具書，是從技能入手的書，這兩種書，我家裡都有，但我發現買了之後，我很少有時間看，下班沒多少時間，北京上班，大多數時間都浪費在地鐵上了，上班時間，看看理論型的吧，覺得啰嗦，浪費時間（後來我發現，做這行，除了會技術，你還是需要去看看牛人眼中的互聯網的，你需要透過前輩的眼光看世界，不要做IT民工，要做互聯網從業者），看看技術型的吧，讓別人看見了感覺你太low，所以我大多數時間還是能在網上down到pdf就在電腦看，down不到網路谷歌我要研究的技術，畢竟從事這行，還是用電腦學技術好點，主要是電腦看久了眼睛會疲憊，偶爾看看紙質的書也不錯的。而以前面試的時候，面試官經常問，除了大學課本，你還看什麼書啊？（如果是你們，恰巧又沒看什麼書，你們怎麼說？），我一般會說，我會自學其他技術，如cocos2dx，然後買一些技術指南之類的書看。我覺得這已經算最大誇張化了，因為大學我真的很少看書，我記憶中就看過一本C++技術類的，一本C#的，一本Android，還有其他幾本是什麼都不大記得了，大學畢竟十幾層的圖書館，除了英語四六級的時候進去復習，其他時間感覺都浪費了這十幾層的圖書館。
說說成長過程中遇到的問題吧，如果遇到我解決不了的，以前是先自己網路谷歌，看看有沒有辦法解決，不行就問老大，而現在，先網路谷歌，看有沒有辦法解決，沒辦法在網路谷歌，實在不行還要看框架源碼如何實現，上國外論壇看外國友人如何解決，問題總能解決的，總會有辦法的。當我開始學習寫架構的時候，我會開始關心游戲的網路層使用什麼框架，mina還是netty，數據怎麼存儲mysql還是mongo，是否需要緩存redis存什麼，memcached存什麼，緩存什麼數據，數據傳輸用什麼協議，json還是protobuffer，怎麼寫效率高，最高支持多少並發等等，我想這些都是我現在需要考慮的問題，當然這些都需要根據游戲具體的需求來決定的，最終伺服器能否高效穩定的運行，都是取決於我的架構是否高效穩定，所以這個過程我要不斷學習，不斷吸取別人的經驗。剛到新公司的時候，我才體會到，自己寫代碼其實也是一種挑戰，整個後端我自己一個人實現，代碼是否規范，數據如何存儲，都是我說了算，我想我的代碼不僅要高效，還要讓別人看得懂，後來的人能接著我的代碼繼續寫下去。
最後說說Java的題外話，語言之爭，從未停過，為什麼有人擁護Java，有人擁護PHP，有人喜歡C#，有人喜歡C++，各個語言各有各的優勢，業余時間，我也了解了不少其他語言，go，node.js我都有了解，我覺得go的語言層面支持協程並發以及node.js的非同步，都是很適合游戲伺服器的，我特別看好node.js，非同步io真的是對游戲伺服器很好的特性，並且加入對原聲js支持的mongo模塊也是很方便的（上面我有說到，我相信nosql是很適合存儲游戲數據的）。說到游戲行業，我認為h5游戲的發展也是越來越快了，上次白鷺的h5開發者生態大會我去了，白鷺的一整套工作流程，以及web vr，真的很令人興奮（第一輪抽獎我還抽了一個暴風魔鏡，哈哈！），另外，大會的模特挺漂亮，哈哈！2015年，互聯網行業也略呈下降趨勢了，不少創業公司面臨倒閉，泡沫經濟破滅，因為很多老闆抓不住當前經濟形勢，以為不管是啥，有個app就是創業了，其實全然不知一款app後面有多少運營模式、盈利模式，就像一句諷刺的話，「我有個絕壁好的idea，可以顛覆bat，什麼都不缺，就缺個程序員了，等等，千萬別告訴馬雲！」，哈哈，聽到這句話，當時我就笑了，估計好多倒閉的創業公司老闆都這么想的吧，他們並不能抓住用戶真正的需求，只有抓住用戶真正的需求，才會抓住用戶的心，真正活下來的，才是用戶真正需要的，然而，相對來說，游戲行業更是復雜多變，或許今天玩家喜歡這種游戲，明天玩家就喜歡另一種游戲了，就像我們永遠也想不到，flappy bird、圍住神經病貓這類的游戲竟然能活起來，愚公移山竟然也能讓h5游戲變為付費的可能。就像一句話，「只要站在風口上，豬也能飛起來！」，只要抓住了玩家此時此刻真正想要的，產品就一定能做起來。