64位整數最大值？如果沒有是C/C語言中，int那是機器位長；Java語言中，int應該是固定不動的32位C/C在64位機中int的的最值是2^63-1，最小值是-2^63java無論在什么系統中大值

64位整數最大值？

如果沒有是C/C語言中，int那是機器位長；Java語言中，int應該是固定不動的32位

C/C在64位機中int的的最值是2^63-1，最小值是-2^63

java無論在什么系統中大值是2^32-1，最小值都是-2^32，的或是_VALUE與Integer.MIN_VALUE

Java和C# 最大的不同是什么？

我覺著不去管語法而談，最主要的還是對底層的控制能力差別。

C#一正在雖然借鑒吸收Java，但是目的全部又不是為了造一個betterJava，只是造一個betterC。游戲引擎們偏愛C#也是有這一層原因在里面。

.例如在C#里面你能干的：

本案所涉代碼會作為輸出10，為什么？因為.NET中數組的長度存儲于數組第一個元素之前的8字節內存中。如果沒有你再隨后輸出低*((way*)p-2)，將是直接得到這個對象的TypeHandle地址：

后再拎著這個指針又隨即能去ftp連接對象的MethodTable。

再有你還可以不自動在棧上分配空間：

而后你想繞到GC真接半自動分配堆內存：

根據上述規定動態鏈接庫互逆于你在C語言中調用的malloc，再者另外AllocAligned、Realloc、AllocZeroed等等，是可以再再控制內存尺寸線。

下一步你想修改一個顯式內存布局的結構Foo：

接著你就成功模擬出了一個C的Union，只是因為會有上面的輸出，是是因為單精度浮點數1的二進制表示為0x00111111100000000000000000000000，以小端存儲后占4個字節，共有是0x00000000、0x00000000、0x10000000、0x00111111。

盡快，你也能真接從內存數據沒有任何文件復制開銷地構造對象：

甚至于那樣的話：

從堆內存創建戰隊恐怕也沒問題啊：

再例如，此時你面前有一個在用Cc語言程序的庫，其中有這么一段代碼：

然后再我們匯編語言萬分感謝C#代碼：

上面的代碼干了什么事情？我們將C#的函數指針傳不到了C代碼中，然后再在C側內部函數C#函數生成氣體了一個字符串wwwww，后再將這個字符串趕往給C#側。而即使不用什么函數指針換了可以使用授權也沒有區別，只不過.NET中的委托下面那是指針變量。

甚至，如果沒有我們并不想讓.NET再導入foo.dll，我們想自身確定代碼庫的生命周期，還可以不這么大寫：

上面這些都又不是Windows專用，在Linux、macOS上導入到.so和.dylib都幾乎也不在話下。

再有，我們有一些數據是想并且算出，只不過我們想可以使用SIMD接受處理，那只需要這么多寫：

可以不看看吧在X86平臺上生成氣體了什么代碼：

平臺確認的分支會被JIT自動永久消除。但當然除此之外不自動匯編語言SIMD代碼之外，前兩個分支全部可以不不寫，而只留下來：

是因為現階段當循環邊界條件是向量長度時，.NET會不自動為我們做向量化并展開攻擊循環。

那就不再，我們另外ref、across、too來做摘錄傳遞。

假設不成立我們有一個很小的struct，我們是為盡量的避免傳遞時再一次發生u盤拷貝，可以不直接用outside來做只讀引用傳遞：

而是對小的struct，.NET有一類的優化幫我們徹底消除掉內存分配，全部將struct裝在寄存器中，例如追加代碼：

本案所涉代碼GetDistance確定是個熱點路徑，但我加來傳授經驗JIT有保證地內聯此函數，結果為Test能生成了萬分感謝的代碼：

全程沒有一句指令訪存，的很的高效。

我們還可以借助ref的引用語義來做原地自動更新：

甚至連能配搭指針和不自動分配內存來可以使用：

C#的泛型不像Java常規擦除，反而真真切切會對所有的類型參數特化代碼（事實上對于引用類型會網絡共享實現區分運行時全部分），這就是能最大程度確保性能，因此隨機的類型強大根據類型參數大小完全不同而特化的內存布局。還是上面那個Point的例子，我們將下面的數據int該成泛型參數T，并做值類型數字的泛型約束：

即便Test1我還是Test2，生成沉淀的代碼都非常極優秀，不僅僅不存在地任何的裝箱拆箱，甚至于沒有任何的訪存你操作：

隨后講，我們有時就是為了低功耗要想充當暫停GC的回收，只要簡單的一句：

就能告知GC如果不是也能分配128mb內存那就別做可以回收了，后再一段時間內以后的代碼我們但他在這個預算內怎么分配內存，任何GC都應該不會發生。哪怕還能夠阻止在內存太少分配的情況下并且阻塞式largeGC：

代碼執行完了，后來的時候內部函數一句：

即可完全恢復GC行為。

除開，我們能在運行時更改GC的模式來最大化性能：

更盡快，我們哪怕也可以就將堆內存中的代碼執行，在.NET上自己造一個JIT，再從內存創建家族一塊可想執行的區域然后往里面塞一段代碼用處將兩個32位整數數字相加：

除此之外，C#也有更多成百上千的底層寫法來和操作系統交互，甚至連用來C#的編譯器取消鏈接到自己的標準庫，直接用從0結束造基礎類型后再是從NativeAOT編譯出徹底無GC、都能夠在裸機硬件上執行強行系統的EFI固件也是沒有問題的，參考

至于還有一個ILGPU讓你把C#代碼直接跑在GPU上面，和跑在嵌入式設備上就能操作I2C、PWM、GPIO等等，就不再舉實例了。

而C#已經進了roadmap的后續更新內容：愿意聲明語句字段、直接添加思想感情固定設置長度內存的類型、不能傳數組時驅除數組分配、容許在棧上分配任何對象等等，無一不是在改進這些底層性能設施。

以上那是我如果說的C#和Java比較大的不同。

在C#中當你不是需要上面這些的東西時，它們好似從來不都不必然，允許代碼類型、不斷地吸收各種函數式特性、還有各種語法糖加持，簡練度和靈巧度哪怕不輸Python，的很快樂滿滿和簡單地就能編寫各種代碼；而否則的話你需要，你也可以強大從上層到底層的甚至已經的控制能力，而這些能力將能讓你有需要時不需要琢磨各種奇怪的的workaround就能再掏空機器，提升C、C的性能，哪怕因為有運行時PGO而遠超過C、C的性能。