作爲一名碼農，我們在windows場景開發，可實際上線時大多數時候是在linux下部署運行的，經歷的一些坑在此記錄下來，是通識性的知識，新秀們遇到的概率大。
先簡單介紹下，我早年是在windows xp做java開發，用的jdk1.4，tomcat5，部署上線環境是在windows server 2003 和windows server 2008場景，隨着linux的普及和大衆化，慢慢的轉移到了centos環境中來，當然也經歷了jdk版本的過渡升遷（1.4，1.6，1.8），tomcat也是如此（5,6,7），中間也用到過weblogic（國企有錢）和oracle 11g（國企有錢，中間件和數據都是正版）。
安裝完乾淨的操作系統後（不知道現在的雲環境做了優化沒有，比如買了ecs），默認參數情況下Linux對高併發支持並不好，主要受限於單進程最大打開文件數限制、內核TCP參數方面和IO事件分配機制等，面就從幾方面來調整使Linux系統能夠支持高併發的場境。
1. 先說說出現的問題：to many open files（花了我好久排查java代碼卻是os層面的），起初通過log日誌排查問題時以爲是java程序本身出現的bug，到後來查閱中英文資料才知道操作系統本身也要做配置的。
在Linux平臺上，無論編寫客戶端程序還是服務端程序，在進行高併發TCP連接處理時，最高的併發數量都要受到系統對用戶單一進程同時可打開文件數量的限制(這是因爲系統爲每個TCP連接都要創建一個socket句柄，每個socket句柄同時也是一個文件句柄)。可使用ulimit命令查看系統允許當前用戶進程打開的文件數限制：
對於java級別的開發人員非系統管理員，務必要關注下參數：open files和 max user processes。
open files: 表示當前用戶的每個進程最多允許同時打開1024個文件，這1024個文件中還得除去每個進程必然打開的標準輸入，標準輸出，標準錯誤，服務器監聽 socket，進程間通訊的unix域socket等文件，那麼剩下的可用於客戶端socket連接的文件數就只有大概1024-10=1014個左右。也就是說缺省情況下，基於Linux的通訊程序最多允許同時1014個TCP併發連接。
對於想支持更高數量的TCP併發連接的通訊處理程序，就必須修改Linux對當前用戶的進程同時打開的文件數量的軟限制(soft limit)和硬限制(hardlimit)。其中軟限制是指Linux在當前系統能夠承受的範圍內進一步限制用戶同時打開的文件數；硬限制則是根據系統硬件資源狀況(主要是系統內存)計算出來的系統最多可同時打開的文件數量。通常軟限制小於或等於硬限制。
Java進程file descriptor table中FD的總量可以通過命令 lsof -p $java_pid | wc -l 查到。
可通過以下方式修改該值：
第一步：編輯 /etc/security/limits.conf ，增加內容
vi /etc/security/limits.conf
#鍵入
* soft nofile 4096
* hard nofile 4096
#然後保存
’注： *’號表示修改所有用戶（也可以指定具體用戶，比如有的中間件轉完後會創建默認用戶）的限制；soft或hard指定要修改軟限制還是硬限制；4096則指定了想要修改的新的限制值，即最大打開文件數(請注意軟限制值要小於或等於硬限制)。修改完後保存文件。
第二步，編輯/etc/pam.d/login文件，在文件中添加如下行：
vi /etc/pam.d/login
#增加
session required /lib/security/pam_limits.so
這是告訴Linux在用戶完成系統登錄後，應該調用pam_limits.so模塊來設置系統對該用戶可使用的各種資源數量的最大限制(包括用戶可打開的最大文件數限制)，而pam_limits.so模塊就會從/etc/security/limits.conf文件中讀取配置來設置這些限制值。修改完後保存此文件。
第三步，查看Linux系統級的最大打開文件數限制，使用如下命令：
cat /proc/sys/fs/file-max
#輸出187932
該值表明這臺Linux系統最多允許同時打開(即包含所有用戶打開文件數總和)文件數，是Linux系統級硬限制，所有用戶級的打開文件數限制都不應超過這個數值。通常這個系統級硬限制是Linux系統在啓動時根據系統硬件資源狀況計算出來的最佳的最大同時打開文件數限制。
如果沒有特殊需要，不應該修改此限制，除非想爲用戶級打開文件數限制設置超過此限制的值。修改此硬限制的方法是修改/etc/sysctl.conf文件內fs.file-max= 187932
這是讓Linux在啓動完成後強行將系統級打開文件數硬限制設置爲187932。修改完後保存此文件。
完成上述步驟後重啓系統，一般情況下就可以將Linux系統對指定用戶的單一進程允許同時打開的最大文件數限制設爲指定的數值。如果重啓後用ulimit-n命令查看用戶可打開文件數限制仍然低於上述步驟中設置的最大值，這可能是因爲在用戶登錄腳本/etc/profile中使用ulimit-n命令已經將用戶可同時打開的文件數做了限制。由於通過ulimit-n修改系統對用戶可同時打開文件的最大數限制時，新修改的值只能小於或等於上次ulimit-n設置的值，因此想用此命令增大這個限制值是不可能的。所以，如果有上述問題存在，就只能去打開/etc/profile腳本文件，在文件中查找是否使用了ulimit-n限制了用戶可同時打開的最大文件數量，如果找到，則刪除這行命令，或者將其設置的值改爲合適的值，然後保存文件，用戶退出並重新登錄系統即可。
至此，就爲支持高併發TCP連接處理的通訊處理程序解除關於打開文件數量方面的系統限制。
2. 網絡方面，出現大量的tcp連接不上
在Linux上編寫支持高併發TCP連接的客戶端通訊處理程序時，有時會發現儘管已經解除了系統對用戶同時打開文件數的限制，但仍會出現併發TCP連接數增加到一定數量時，再也無法成功建立新的TCP連接的現象。出現這種現在的原因有多種。
第一種情況：可能是因爲Linux網絡內核對本地端口號範圍有限制。此時，進一步分析爲什麼無法建立TCP連接，會發現問題出在connect()調用返回失敗，查看系統錯誤提示消息是“Can’t assign requested address”。同時，如果在此時用tcpdump工具監視網絡，會發現根本沒有TCP連接時客戶端發SYN包的網絡流量。這些情況說明問題在於本地Linux系統內核中有限制。其實，問題的根本原因在於Linux內核的TCP/ip協議實現模塊對系統中所有的客戶端TCP連接對應的本地端口號的範圍進行了限制(例如，內核限制本地端口號的範圍爲1024~32768之間)。
當系統中某一時刻同時存在太多的TCP客戶端連接時，由於每個TCP客戶端連接都要佔用一個唯一的本地端口號(此端口號在系統的本地端口號範圍限制中)，如果現有的TCP客戶端連接已將所有的本地端口號佔滿，則此時就無法爲新的TCP客戶端連接分配一個本地端口號了，因此係統會在這種情況下在connect()調用中返回失敗，並將錯誤提示消息設爲“Can’t assign requested address”。有關這些控制邏輯可以查看Linux內核源代碼，以linux2.6內核爲例，可以查看tcp_ipv4.c文件中如下函數：
static int tcp_v4_hash_connect(struct sock *sk)
請注意上述函數中對變量sysctl_local_port_range的訪問控制。變量sysctl_local_port_range的初始化則是在tcp.c文件中的如下函數中設置：
void __init tcp_init(void)
內核編譯時默認設置的本地端口號範圍可能太小，因此需要修改此本地端口範圍限制。
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
vi /etc/sysctl.conf
#添加
net.ipv4.ip_local_port_range = 1024 65000
這表明將系統對本地端口範圍限制設置爲1024~65000之間。請注意，本地端口範圍的最小值必須大於或等於1024；而端口範圍的最大值則應小於或等於65535。修改完後保存此文件。
第二步，執行sysctl命令：
sysctl -p
如果系統沒有錯誤提示，就表明新的本地端口範圍設置成功。如果按上述端口範圍進行設置，則理論上單獨一個進程最多可以同時建立60000多個TCP客戶端連接。
第二種情況：無法建立TCP連接的原因可能是因爲Linux網絡內核的IP_TABLE防火牆對最大跟蹤的TCP連接數有限制。此時程序會表現爲在 connect()調用中阻塞，如同死機，如果用tcpdump工具監視網絡，也會發現根本沒有TCP連接時客戶端發SYN包的網絡流量。由於 IP_TABLE防火牆在內核中會對每個TCP連接的狀態進行跟蹤，跟蹤信息將會放在位於內核內存中的conntrack database中，這個數據庫的大小有限，當系統中存在過多的TCP連接時，數據庫容量不足，IP_TABLE無法爲新的TCP連接建立跟蹤信息，於是表現爲在connect()調用中阻塞。此時就必須修改內核對最大跟蹤的TCP連接數的限制，方法同修改內核對本地端口號範圍的限制是類似的：
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
vi /etc/sysctl.conf
#追加
net.ipv4.ip_conntrack_max = 10240
這表明將系統對最大跟蹤的TCP連接數限制設置爲10240。請注意，此限制值要儘量小，以節省對內核內存的佔用。
第二步，執行sysctl命令：
sysctl -p
如果系統沒有錯誤提示，就表明系統對新的最大跟蹤的TCP連接數限制修改成功。如果按上述參數進行設置，則理論上單獨一個進程最多可以同時建立10000多個TCP客戶端連接。
第三種情況： TCP連接斷開後，會以TIME_WAIT狀態保留一定的時間，然後纔會釋放端口。當併發請求過多的時候，就會產生大量的TIME_WAIT狀態的連接，無法及時斷開的話，會佔用大量的端口資源和服務器資源。這個時候我們可以優化TCP的內核參數，來及時將TIME_WAIT狀態的端口清理掉。
下面介紹的方法只對擁有大量TIME_WAIT狀態的連接導致系統資源消耗有效，如果不是這種情況下，效果可能不明顯。可以使用netstat命令去查TIME_WAIT狀態的連接狀態，輸入下面的組合命令，查看當前TCP連接的狀態和對應的連接數量：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
這個命令會輸出類似下面的結果：
LAST_ACK16
SYN_RECV348
ESTABLISHED70
FIN_WAIT1229
FIN_WAIT230
CLOSING33
TIME_WAIT18098
我們只用關心TIME_WAIT的個數，在這裏可以看到，有18000多個TIME_WAIT，這樣就佔用了18000多個端口。要知道端口的數量只有65535個，佔用一個少一個，會嚴重的影響到後繼的新連接。這種情況下，我們就有必要調整下Linux的TCP內核參數，讓系統更快的釋放TIME_WAIT連接。
編輯配置文件:/etc/sysctl.conf，在這個文件中，加入下面的幾行內容：
# vi /etc/sysctl.conf
net.ipv4.tcp_syncookies= 1
net.ipv4.tcp_tw_reuse= 1
net.ipv4.tcp_tw_recycle= 1
net.ipv4.tcp_fin_timeout= 30
輸入下面的命令，讓內核參數生效：
# sysctl-p
簡單的說明上面的參數的含義：
net.ipv4.tcp_syncookies= 1
表示開啓SYNCookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少量SYN攻擊，默認爲0，表示關閉；
net.ipv4.tcp_tw_reuse= 1
表示開啓重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認爲0，表示關閉；
net.ipv4.tcp_tw_recycle= 1
表示開啓TCP連接中TIME-WAITsockets的快速回收，默認爲0，表示關閉；
net.ipv4.tcp_fin_timeout
修改系統默認的TIMEOUT 時間。
在經過這樣的調整之後，除了會進一步提升服務器的負載能力之外，還能夠防禦小流量程度的DoS、CC和SYN攻擊。
此外，如果你的連接數本身就很多，我們可以再優化一下TCP的可使用端口範圍，進一步提升服務器的併發能力。依然是往上面的參數文件中，加入下面這些配置：
net.ipv4.tcp_keepalive_time= 1200
net.ipv4.ip_local_port_range= 1024 65535
net.ipv4.tcp_max_syn_backlog= 8192
net.ipv4.tcp_max_tw_buckets= 5000
這幾個參數，建議只在流量非常大的服務器上開啓，會有顯著的效果。一般的流量小的服務器上，沒有必要去設置這幾個參數。
net.ipv4.tcp_keepalive_time= 1200
表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改爲20分鐘。
ip_local_port_range= 1024 65535
表示用於向外連接的端口範圍。缺省情況下很小，改爲1024到65535。
net.ipv4.tcp_max_syn_backlog= 8192
表示SYN隊列的長度，默認爲1024，加大隊列長度爲8192，可以容納更多等待連接的網絡連接數。
net.ipv4.tcp_max_tw_buckets= 5000
表示系統同時保持TIME_WAIT的最大數量，如果超過這個數字，TIME_WAIT將立刻被清除並打印警告信息。默認爲180000，改爲5000。此項參數可以控制TIME_WAIT的最大數量，只要超出了。
net.ipv4.tcp_max_syn_backlog= 65536
記錄的那些尚未收到客戶端確認信息的連接請求的最大值。對於有128M內存的系統而言，缺省值是1024，小內存的系統則是128。
net.core.netdev_max_backlog= 32768
每個網絡接口接收數據包的速率比內核處理這些包的速率快時，允許送到隊列的數據包的最大數目。
net.core.somaxconn= 32768
例如web應用中listen函數的backlog默認會給我們內核參數的net.core.somaxconn限制到128，而nginx定義的NGX_LISTEN_BACKLOG默認爲511，所以有必要調整這個值。
net.core.wmem_default= 8388608
net.core.rmem_default= 8388608
net.core.rmem_max= 16777216 #最大socket讀buffer,可參考的優化值:873200
net.core.wmem_max= 16777216 #最大socket寫buffer,可參考的優化值:873200
net.ipv4.tcp_timestsmps= 0
時間戳可以避免序列號的卷繞。一個1Gbps的鏈路肯定會遇到以前用過的序列號。時間戳能夠讓內核接受這種“異常”的數據包。這裏需要將其關掉。
net.ipv4.tcp_synack_retries= 2
爲了打開對端的連接，內核需要發送一個SYN並附帶一個迴應前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設置決定了內核放棄連接之前發送SYN+ACK包的數量。
net.ipv4.tcp_syn_retries= 2
在內核放棄建立連接之前發送SYN包的數量。
#net.ipv4.tcp_tw_len= 1
net.ipv4.tcp_tw_reuse= 1
開啓重用。允許將TIME-WAITsockets重新用於新的TCP連接。
net.ipv4.tcp_wmem= 8192 436600 873200
TCP寫buffer,可參考的優化值:8192 436600 873200
net.ipv4.tcp_rmem = 32768 436600 873200
TCP讀buffer,可參考的優化值:32768 436600 873200
net.ipv4.tcp_mem= 94500000 91500000 92700000
同樣有3個值,意思是:
net.ipv4.tcp_mem[0]:低於此值，TCP沒有內存壓力。
net.ipv4.tcp_mem[1]:在此值下，進入內存壓力階段。
net.ipv4.tcp_mem[2]:高於此值，TCP拒絕分配socket。
上述內存單位是頁，而不是字節。可參考的優化值是:7864321048576 1572864
net.ipv4.tcp_max_orphans= 3276800
系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。
如果超過這個數字，連接將即刻被複位並打印出警告信息。
這個限制僅僅是爲了防止簡單的DoS攻擊，不能過分依靠它或者人爲地減小這個值，
更應該增加這個值(如果增加了內存之後)。
net.ipv4.tcp_fin_timeout= 30
如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間。對端可以出錯並永遠不關閉連接，甚至意外當機。缺省值是60秒。2.2 內核的通常值是180秒，你可以按這個設置，但要記住的是，即使你的機器是一個輕載的WEB服務器，也有因爲大量的死套接字而內存溢出的風險，FIN-WAIT-2的危險性比FIN-WAIT-1要小，因爲它最多隻能吃掉1.5K內存，但是它們的生存期長些。
同時還涉及到一個TCP 擁塞算法的問題，你可以用下面的命令查看本機提供的擁塞算法控制模塊：
sysctlnet.ipv4.tcp_available_congestion_control
對於幾種算法的分析，詳情可以參考下：TCP擁塞控制算法的優缺點、適用環境、性能分析，比如高延時可以試用hybla，中等延時可以試用htcp算法等。
如果想設置TCP 擁塞算法爲hybla
net.ipv4.tcp_congestion_control=hybla
額外的，對於內核版高於於3.7.1的，我們可以開啓tcp_fastopen：
net.ipv4.tcp_fastopen= 3
3、使用支持高併發網絡I/O的編程技術（可參考Unix網絡編程一書）
在Linux上編寫高併發TCP連接應用程序時，必須使用合適的網絡I/O技術和I/O事件分派機制。
可用的I/O技術有同步I/O，非阻塞式同步I/O(也稱反應式I/O)，以及異步I/O。在高TCP併發的情形下，如果使用同步I/O，這會嚴重阻塞程序的運轉，除非爲每個TCP連接的I/O創建一個線程。但是，過多的線程又會因系統對線程的調度造成巨大開銷。因此，在高TCP併發的情形下使用同步 I/O是不可取的，這時可以考慮使用非阻塞式同步I/O或異步I/O。非阻塞式同步I/O的技術包括使用select()，poll()，epoll等機制。異步I/O的技術就是使用AIO。
從I/O事件分派機制來看，使用select()是不合適的，因爲它所支持的併發連接數有限(通常在1024個以內)。如果考慮性能，poll()也是不合適的，儘管它可以支持的較高的TCP併發數，但是由於其採用“輪詢”機制，當併發數較高時，其運行效率相當低，並可能存在I/O事件分派不均，導致部分TCP連接上的I/O出現“飢餓”現象。而如果使用epoll或AIO，則沒有上述問題(早期Linux內核的AIO技術實現是通過在內核中爲每個 I/O請求創建一個線程來實現的，這種實現機制在高併發TCP連接的情形下使用其實也有嚴重的性能問題。但在最新的Linux內核中，AIO的實現已經得到改進)。
綜上所述，在開發支持高併發TCP連接的Linux應用程序時，應儘量使用epoll或AIO技術來實現併發的TCP連接上的I/O控制，這將爲提升程序對高併發TCP連接的支持提供有效的I/O保證。
4. 日誌裏出現了“ java.lang.OutOfMemoryError: ”
從兩方面論述，操作系統和java方面
4.1 操作系統配置
一開始的印象是java應用程序代碼的問題，也很有機率是系統沒有做參數優化，繼續編輯 /etc/security/limits.conf 文件
vi /etc/security/limits.conf
#追加
• soft nproc 81920
• hard nproc 81920
注： * 表示所有用戶，soft、hard表示軟限制、硬限制。（軟限制<=硬限制）
4.2 jvm方面的參數配置
jvm結構圖：
1,JVM內存劃分分爲年輕代（Young Generation）、老年代（Old Generation）、永久代（Permanent Generation）。
2,年輕代又分爲Eden和Survivor區。Survivor區由FromSpace和ToSpace組成。Eden區佔大容量，Survivor兩個區佔小容量，默認比例大概是8:2。
3,堆內存（Heap）=年輕代+老年代。非堆內存=永久代。
4,堆內存用途：存放的是對象，垃圾收集器就是收集這些對象，然後根據GC算法回收。
5,非堆內存用途：JVM本身使用，存放一些類、方法、常量、屬性等。
6,年輕代：新生成的對象首先放到年輕代的Eden區中，當Eden滿時，經過GC後，還存活的對象被複制到Survivor區的FromSpace中，如果Survivor區滿時，會再被複制到Survivor區的ToSpace區。如果還有存活對象，會再被複制到老年代。
7,老年代：在年輕代中經過GC後還存活的對象會被複制到老年代中。當老年代空間不足時，JVM會對老年代進行完全的垃圾回收（Full GC）。如果GC後，還是無法存放從Survivor區複製過來的對象，就會出現OOM（Out of Memory）。
8,永久代：也稱爲方法區，存放靜態類型數據，比如類、方法、屬性等。
JVM內存設置不是越大越好，具體還是根據項目對象實際佔用內存大小而定，可以通過Java自帶的分析工具來查看。如果設置過大，會增加回收時間，從而增加暫停應用時間，而且從未遇到過專門弄臺服務器跑java程序，都是混合式場景跑着數據庫，tomcat，nginx等
#按需配置優化，這只是參考
JAVA_OPTS="-server-Xms1024m -Xmx1536m -XX:PermSize=256m -XX:MaxPermSize=512m-XX:+UseConcMarkSweepGC -XX:+UseParallelGCThreads=8XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0 -XX:-PrintGC -XX:-PrintGCDetails-XX:-PrintGCTimeStamps -Xloggc:/log/java.log"
5. 通過tomcat（開源免費）優化配置，略
#只是參考，實際場景看需要
<Connectorport="8080"protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="1000"
minSpareThreads="100"
maxSpareThreads="200"
acceptCount="900"
disableUploadTimeout="true"
connectionTimeout="20000"
URIEncoding="UTF-8"
enableLookups="false"
redirectPort="8443"
compression="on"
compressionMinSize="1024"
compressableMimeType="text/html,text/xml,text/css,text/javascript"/>
參數說明：
org.apache.coyote.http11.Http11NioProtocol：調整工作模式爲Nio
maxThreads：最大線程數，默認150。增大值避免隊列請求過多，導致響應緩慢。
minSpareThreads：最小空閒線程數。
maxSpareThreads：最大空閒線程數，如果超過這個值，會關閉無用的線程。
acceptCount：當處理請求超過此值時，將後來請求放到隊列中等待。
disableUploadTimeout：禁用上傳超時時間
connectionTimeout：連接超時，單位毫秒，0代表不限制
URIEncoding：URI地址編碼使用UTF-8
enableLookups：關閉dns解析，提高響應時間
compression：啓用壓縮功能
compressionMinSize：最小壓縮大小，單位Byte
compressableMimeType：壓縮的文件類型
Tomcat有三種工作模式：Bio、Nio和Apr
下面簡單瞭解下他們工作原理：
Bio(BlockingI/O)：默認工作模式，阻塞式I/O操作，沒有任何優化技術處理，性能比較低。
Nio(New I/O orNon-Blocking)：非阻塞式I/O操作，有Bio有更好的併發處理性能。
Apr(ApachePortable Runtime，Apache可移植運行庫)：首選工作模式，主要爲上層的應用程序提供一個可以跨越多操作系統平臺使用的底層支持接口庫。
tomcat利用基於Apr庫tomcat-native來實現操作系統級別控制，提供一種優化技術和非阻塞式I/O操作，大大提高併發處理能力。但是需要安裝apr和tomcat-native庫。
附一份參考 內核參數sysctl.conf （實際場景中做調整）：
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
轉存失敗重新上傳取消
轉存失敗重新上傳取消轉存失敗重新上傳取消總結基本上完畢，如有新情況接着寫。。。學好linux，對java從業人員有益無害，推薦兩本書《深入理解計算機系統》和Unix網絡編程卷1