WebSocketServerProtocolHandler的本質是MessageToMessageDecoderWebSocketFrame,也就是別的handler把數據轉成WebSocketFrame之後,數據到它這兒,他才能處理,但是demo代碼裏沒有手動添加一個將ByteBuf轉成WebSocketFrame的handler,這個問題好像通義也沒有收錄,最終在chatgpt4o那裏找
背景:最近接觸netty以及自己寫"包一層"的設計,包一層 是指在原生netty的api上再包一層api,稱作項目common,因為項目是對接不同上游,所以才做的common,有了一些理解和想法 理解:為什麼有時候既要有接口,又要有該接口的抽象類:接口的抽象性更強,適應變化性也更強,抽象類就多了一些成員變量,默認方法實現,模板方法等,這些都是不可變的,變化性不那麼強.之所以兩者都保留, 目的
背景,複習以前項目的時候,結合通義千問/kimi.ai,詳細掰扯了一下單點登錄,有了新的認識 單點登錄的範圍,肯定是同一台機器,或者同一類客户端,比如瀏覽器,或者專門的客户端軟件,至於同一台機器上的不同客户端能不能其中一個登錄了,其他的也自動登錄,這個感覺要更復雜,要藉助文件系統來搞.感覺一般討論的單點登錄是同一個機器上的同一個瀏覽器,並且瀏覽器支持localStorage,查了下,2010
以前工作時,一位前輩習慣拆方法,把一個很長的方法拆成多個小方法,當時費解,直到此時此刻 當時覺得,沒必要啊,我看代碼熟悉業務的時候,還得來回返回,一整個大方法,看起來多方便 剛才,我在寫一個複雜的方法,因為代碼複用,拆出了很多小方法, 這算是需要拆方法的原因之一 關鍵是,當我在改某個方法的時候, 突然忘了這個方法是幹嘛的了,就往上翻註釋,而方法太大,翻到了很多if/else,而我不得不把
背景：java網絡編程框架底層的多路複用的 面向對象設計 NioEventLoopGroup：上層是bootstrap起動器，下層是selector。 從學習過程中的案例可以看出，EventLoopGroup裏有多個線程， 這些線程從管理連接通道（channel），處理channel上的讀寫事件，此時就出現了selector和selectionKey selector：幹活的，從註冊的so
本文觸發點:讀spring揭秘 説人話,ioc幹了啥？通過反射幫你自動地把組合(依賴)的對象賦值(setter).lombok是幫你寫getter/setter/constructor/builder,ioc就類似的,幫你把 你定義的service,set到依賴它的地方. 為什麼這麼搞？設計原則裏的一條規則:單一職責原則.每個類都有自己的單一的職責,這裏就感覺説的很清楚但有很費解,因為缺了界限,多
