@Component
public class MyBeanPostProcessor implements BeanPostProcessor{
//在每個bean初始化后，初始化方法執行后，都執行
的方法
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
System.out.println("postProcessAfterInitialization=="+beanName);
return BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
}
//在每個bean初始化后，在初始化方法執行前，都執行的方法
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
System.out.println("postProcessBeforeInitialization=="+beanName);
return BeanPostProcessor.super.postProcessBeforeInitialization(bean, beanName);
}
}
三種初始化方式
public class Cat {
@PostConstruct//初始化
public void afterPropertiesSet() throws Exception {
System.out.println(" cat init");
}
@PreDestroy//銷毀
public void destroy() throws Exception {
System.out.println("cat destroy");
}
}
public class User implements InitializingBean,DisposableBean{
public String toString() {
return "444";
}
@Override//初始化
public void afterPropertiesSet() throws Exception {
System.out.println(" user afterPropertiesSet");
}
@Override//銷毀
public void destroy() throws Exception {
System.out.println("user destroy");
}
}
public class Room {
//初始化
public void afterPropertiesSet() throws Exception {
System.out.println(" room afterPropertiesSet");
}
//銷毀
public void destroy() throws Exception {
System.out.println("room destroy");
}
}
@Configuration
public class Cfg1 {
@Bean
public Cat getCat() {
return new Cat();
}
@Bean
public User getUser() {
return new User();
}
@Bean(initMethod="afterPropertiesSet",destroyMethod="destroy")
public Room getRoom() {
return new Room();
}
}
@Configuration
public class RedisClusterConfig {
@Value("${spring.redis.cluster.nodes}")
private String clusterNodes;
@Bean
public JedisCluster getJedisCluster() {
// 截取集群節點
String[] cluster = clusterNodes.split(",");
// 創建set集合
Set<HostAndPort> nodes = new HashSet<HostAndPort>();
// 循環數組把集群節點添加到set集合中
for (String node : cluster) {
String[] host = node.split(":");
//添加集群節點
nodes.add(new HostAndPort(host[0], Integer.parseInt(host[1])));
}
JedisCluster jc = new JedisCluster(nodes);
return jc;
}
}
在application.properties文件中，配置spring.redis.cluster.nodes=
在使用的時候直接得到JedisCluster對象使用
一、Redis提供了哪些持久化機制：
1). RDB持久化：
該機制是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。
2). AOF持久化:
該機制將以日志的形式記錄服務器所處理的每一個寫操作，在Redis服務器啟動之初會讀取該文件來重新構建數據庫，以保證啟動后數據庫中的數據是完整的。
3). 無持久化：
我們可以通過配置的方式禁用Redis服務器的持久化功能，這樣我們就可以將Redis視為一個功能加強版的memcached了。
4). 同時應用AOF和RDB。
二、RDB機制的優勢和劣勢：
RDB存在哪些優勢呢？
1). 一旦采用該方式，那么你的整個Redis數據庫將只包含一個文件，這對于文件備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的數據，同時還要每天歸檔一次最近30天的數據。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
2). 對于災難恢復而言，RDB是非常不錯的選擇。因為我們可以非常輕松的將一個單獨的文件壓縮后再轉移到其它存儲介質上。
3). 性能最大化。對于Redis的服務進程而言，在開始持久化時，它唯一需要做的只是fork出子進程，之后再由子進程完成這些持久化的工作，這樣就可以極大的避免服務進程執行IO操作了。
4). 相比于AOF機制，如果數據集很大，RDB的啟動效率會更高。
RDB又存在哪些劣勢呢？
1). 如果你想保證數據的高可用性，即最大限度的避免數據丟失，那么RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。
2). 由于RDB是通過fork子進程來協助完成數據持久化工作的，因此，如果當數據集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是1秒鐘。
三、AOF機制的優勢和劣勢：
AOF的優勢有哪些呢？
1). 該機制可以帶來更高的數據安全性，即數據持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事實上，每秒同步也是異步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那么這一秒鐘之內修改的數據將會丟失。而每修改同步，我們可以將其視為同步持久化，即每次發生的數據變化都會被立即記錄到磁盤中。可以預見，這種方式在效率上是最低的。至于無同步，無需多言，我想大家都能正確的理解它。
2). 由于該機制對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日志文件中已經存在的內容。然而如果我們本次操作只是寫入了一半數據就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來幫助我們解決數據一致性的問題。
3). 如果日志過大，Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改數據寫入到老的磁盤文件中，同時Redis還會創建一個新的文件用于記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證數據安全性。
4). AOF包含一個格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實上，我們也可以通過該文件完成數據的重建。
AOF的劣勢有哪些呢？
1). 對于相同數量的數據集而言，AOF文件通常要大于RDB文件。
2). 根據同步策略的不同，AOF在運行效率上往往會慢于RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。
四、其它：
1. Snapshotting:
缺省情況下，Redis會將數據集的快照dump到dump.rdb文件中。此外，我們也可以通過配置文件來修改Redis服務器dump快照的頻率，在打開6379.conf文件之后，我們搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分鐘)之后，如果至少有1個key發生變化，則dump內存快照。
save 300 10 #在300秒(5分鐘)之后，如果至少有10個key發生變化，則dump內存快照。
save 60 10000 #在60秒(1分鐘)之后，如果至少有10000個key發生變化，則dump內存快照。
2. Dump快照的機制：
1). Redis先fork子進程。
2). 子進程將快照數據寫入到臨時RDB文件中。
3). 當子進程完成數據寫入操作后，再用臨時文件替換老的文件。
3. AOF文件：
上面已經多次講過，RDB的快照定時dump機制無法保證很好的數據持久性。如果我們的應用確實非常關注此點，我們可以考慮使用Redis中的AOF機制。對于Redis服務器而言，其缺省的機制是RDB，如果需要使用AOF，則需要修改配置文件中的以下條目：
將appendonly no改為appendonly yes
從現在起，Redis在每一次接收到數據修改的命令之后，都會將其追加到AOF文件中。在Redis下一次重新啟動時，需要加載AOF文件中的信息來構建最新的數據到內存中。
4. AOF的配置：
在Redis的配置文件中存在三種同步方式，它們分別是：
appendfsync always #每次有數據修改發生時都會寫入AOF文件。
appendfsync everysec #每秒鐘同步一次，該策略為AOF的缺省策略。
appendfsync no #從不同步。高效但是數據不會被持久化。
5. 如何修復壞損的AOF文件：
1). 將現有已經壞損的AOF文件額外拷貝出來一份。
2). 執行"redis-check-aof --fix <filename>"命令來修復壞損的AOF文件。
3). 用修復后的AOF文件重新啟動Redis服務器。
6. Redis的數據備份：
在Redis中我們可以通過copy的方式在線備份正在運行的Redis數據文件。這是因為RDB文件一旦被生成之后就不會再被修改。Redis每次都是將最新的數據dump到一個臨時文件中，之后在利用rename函數原子性的將臨時文件改名為原有的數據文件名。因此我們可以說，在任意時刻copy數據文件都是安全的和一致的。鑒于此，我們就可以通過創建cron job的方式定時備份Redis的數據文件，并將備份文件copy到安全的磁盤介質中。
安裝
1/到官網下載最新stable版
2/解壓源碼并進入目錄
3/ make
4/ 可選 make test （可能出現need tcl>8.4,yum install tcl）
5/安裝到指定目錄,如 /usr/local/redis
make PREFIX=/usr/local/redis install
運行
./bin/redis-server redis-2.8.19/redis.conf
(默認前端運行模式。后臺進程模式： 修改conf daemonize yes)
連接
[root@bogon redis]# ./bin/redis-cli
127.0.0.1:6379> set a bb
OK
127.0.0.1:6379> get a
"bb"
127.0.0.1:6379> get aa
(nil)
127.0.0.1:6379>
后來發現了logratate這個工具，Ubuntu
下的mysql，nginx好像也是用的這個工具還定期整理log的。配置文件為/etc/logrotate.conf，和很多其它ubuntu下的工
具一下，也可以把配置文件寫在/etc/logrotate.d/下面。如對我們的tomcat的log文件進行整理，sudo vi
/etc/logrotate.d/tomcat，
/opt/tomcat/logs/catalina.out {
rotate 14
daily
copytruncate
compress
notifempty
missingok
}
其中：
rotate 7 表示保留7天的備份文件
daily 表示每天整理一次
copytruncate 表示先復制log文件的內容，然后再清空
compress 表示壓縮備分文件
missingok 表示如果找不到log文件也沒OK
notifempty 表示如果log文件是空的，就不進行rotate
可以通過/usr/sbin/logrotate -f /etc/logrotate.conf來執行。Ubuntu
有/etc/cron.daily/logrotate文件，內容為:
#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf
表示每天會定時執行一次這個命令
通過ntp同步服務器的時間
根據 Ubuntu 的文檔 有兩種方式可以用來使服務器的時間和ntp server同步。一種是通過ntpdate命令，如
ntpdate ntp.Ubuntu .com
然后在/etc/cron.daily/下新建一個文件來每天執行一次這個命令
另一種是通過ntpd來更新。sudo apt-get install
ntp。配置文件/etc/ntp.conf，可以通過修改配置文件為改變ntp server，
我們用的是210.72.145.44這個server
對于Linux 的系統安全來說，日志文件是極其重要的工具。系統管理員可以使用logrotate
程序用來管理系統中的最新的事件，對于Linux 的系統安全來說，日志文件是極其重要的工具。系統管理員可以使用logrotate
程序用來管理系統中的最新的事件。logrotate 還可以用來備份日志文件，本篇將通過以下幾部分來介紹
日志文件的管理：
1、logrotate 配置
2、缺省配置 logrotate
3、使用include 選項讀取其他配置文件
4、使用include 選項覆蓋缺省配置
5、為指定的文件配置轉儲參數
一、logrotate 配置
logrotate
程序是一個日志文件管理工具。用來把舊的日志文件刪除，并創建新的日志文件，我們把它叫做“轉儲”。我們可以根據日志文件的大小，也可以根據其天數來轉儲，這個過程一般通過
cron 程序來執行。
logrotate 程序還可以用于壓縮日志文件，以及發送日志到指定的E-mail 。
logrotate 的配置文件是 /etc/logrotate.conf。主要參數如下表：
參數 功能
compress 通過gzip 壓縮轉儲以后的日志
nocompress 不需要壓縮時，用這個參數
copytruncate 用于還在打開中的日志文件，把當前日志備份并截斷
nocopytruncate 備份日志文件但是不截斷
create mode owner group 轉儲文件，使用指定的文件模式創建新的日志文件
nocreate 不建立新的日志文件
delaycompress 和 compress 一起使用時，轉儲的日志文件到下一次轉儲時才壓縮
nodelaycompress 覆蓋 delaycompress 選項，轉儲同時壓縮。
errors address 專儲時的錯誤信息發送到指定的Email 地址
ifempty 即使是空文件也轉儲，這個是 logrotate 的缺省選項。
notifempty 如果是空文件的話，不轉儲
mail address 把轉儲的日志文件發送到指定的E-mail 地址
nomail 轉儲時不發送日志文件
olddir directory 轉儲后的日志文件放入指定的目錄，必須和當前日志文件在同一個文件系統
noolddir 轉儲后的日志文件和當前日志文件放在同一個目錄下
prerotate/endscript 在轉儲以前需要執行的命令可以放入這個對，這兩個關鍵字必須單獨成行
postrotate/endscript 在轉儲以后需要執行的命令可以放入這個對，這兩個關鍵字必須單獨成行
daily 指定轉儲周期為每天
weekly 指定轉儲周期為每周
monthly 指定轉儲周期為每月
rotate count 指定日志文件刪除之前轉儲的次數，0 指沒有備份，5 指保留5 個備份
tabootext [+] list 讓logrotate 不轉儲指定擴展名的文件，缺省的擴展名是：.rpm-orig,
.rpmsave, v, 和 ~
size size 當日志文件到達指定的大小時才轉儲，Size 可以指定 bytes (缺省)以及KB
(sizek)或者MB (sizem).cat /dev/null >catalina.out
后來發現了logratate這個工具，Ubuntu
下的mysql，nginx好像也是用的這個工具還定期整理log的。配置文件為/etc/logrotate.conf，和很多其它ubuntu下的工
具一下，也可以把配置文件寫在/etc/logrotate.d/下面。如對我們的tomcat的log文件進行整理，sudo vi
/etc/logrotate.d/tomcat，
/opt/tomcat/logs/catalina.out {
rotate 14
daily
copytruncate
compress
notifempty
missingok
}
其中：
rotate 7 表示保留7天的備份文件
daily 表示每天整理一次
copytruncate 表示先復制log文件的內容，然后再清空
compress 表示壓縮備分文件
missingok 表示如果找不到log文件也沒OK
notifempty 表示如果log文件是空的，就不進行rotate
可以通過/usr/sbin/logrotate -f /etc/logrotate.conf來執行。Ubuntu
有/etc/cron.daily/logrotate文件，內容為:
#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf
表示每天會定時執行一次這個命令
通過ntp同步服務器的時間
根據 Ubuntu 的文檔 有兩種方式可以用來使服務器的時間和ntp server同步。一種是通過ntpdate命令，如
ntpdate ntp.Ubuntu .com
然后在/etc/cron.daily/下新建一個文件來每天執行一次這個命令
另一種是通過ntpd來更新。sudo apt-get install
ntp。配置文件/etc/ntp.conf，可以通過修改配置文件為改變ntp server，
我們用的是210.72.145.44這個server
對于Linux 的系統安全來說，日志文件是極其重要的工具。系統管理員可以使用logrotate
程序用來管理系統中的最新的事件，對于Linux 的系統安全來說，日志文件是極其重要的工具。系統管理員可以使用logrotate
程序用來管理系統中的最新的事件。logrotate 還可以用來備份日志文件，本篇將通過以下幾部分來介紹
日志文件的管理：
1、logrotate 配置
2、缺省配置 logrotate
3、使用include 選項讀取其他配置文件
4、使用include 選項覆蓋缺省配置
5、為指定的文件配置轉儲參數
一、logrotate 配置
logrotate
程序是一個日志文件管理工具。用來把舊的日志文件刪除，并創建新的日志文件，我們把它叫做“轉儲”。我們可以根據日志文件的大小，也可以根據其天數來轉儲，這個過程一般通過
cron 程序來執行。
logrotate 程序還可以用于壓縮日志文件，以及發送日志到指定的E-mail 。
logrotate 的配置文件是 /etc/logrotate.conf。主要參數如下表：
參數 功能
compress 通過gzip 壓縮轉儲以后的日志
nocompress 不需要壓縮時，用這個參數
copytruncate 用于還在打開中的日志文件，把當前日志備份并截斷
nocopytruncate 備份日志文件但是不截斷
create mode owner group 轉儲文件，使用指定的文件模式創建新的日志文件
nocreate 不建立新的日志文件
delaycompress 和 compress 一起使用時，轉儲的日志文件到下一次轉儲時才壓縮
nodelaycompress 覆蓋 delaycompress 選項，轉儲同時壓縮。
errors address 專儲時的錯誤信息發送到指定的Email 地址
ifempty 即使是空文件也轉儲，這個是 logrotate 的缺省選項。
notifempty 如果是空文件的話，不轉儲
mail address 把轉儲的日志文件發送到指定的E-mail 地址
nomail 轉儲時不發送日志文件
olddir directory 轉儲后的日志文件放入指定的目錄，必須和當前日志文件在同一個文件系統
noolddir 轉儲后的日志文件和當前日志文件放在同一個目錄下
prerotate/endscript 在轉儲以前需要執行的命令可以放入這個對，這兩個關鍵字必須單獨成行
postrotate/endscript 在轉儲以后需要執行的命令可以放入這個對，這兩個關鍵字必須單獨成行
daily 指定轉儲周期為每天
weekly 指定轉儲周期為每周
monthly 指定轉儲周期為每月
rotate count 指定日志文件刪除之前轉儲的次數，0 指沒有備份，5 指保留5 個備份
tabootext [+] list 讓logrotate 不轉儲指定擴展名的文件，缺省的擴展名是：.rpm-orig,
.rpmsave, v, 和 ~
size size 當日志文件到達指定的大小時才轉儲，Size 可以指定 bytes (缺省)以及KB
(sizek)或者MB (sizem).
原文來自http://note.youdao.com/share/web/file.html?id=236896997b6ffbaa8e0d92eacd13abbf&type=note
我怕鏈接會失效，故轉載此篇文章
由于linux目前很熱門，越來越多的人在學習linux，但是買一臺服務放家里來學習，實在是很浪費。那么如何解決這個問題？虛擬機軟件是很好的選擇，常用的虛擬機軟件有vmware workstations和virtual box等。在使用虛擬機軟件的時候，很多初學者都會遇到很多問題，而vmware的網絡連接問題是大家遇到最多問題之一。在學習交流群里面，幾乎每天都會有同學問到這些問題，寫這篇詳解也是因為群里童鞋網絡出故障，然后在幫他解決的過程中，對自己的理解也做一個總結。接下來，我們就一起來探討一下關于vmware workstations網絡連接的三種模式。
vmware為我們提供了三種網絡工作模式，它們分別是：Bridged（橋接模式）、NAT（網絡地址轉換模式）、Host-Only（僅主機模式）。
打開vmware虛擬機，我們可以在選項欄的“編輯”下的“虛擬網絡編輯器”中看到VMnet0（橋接模式）、VMnet1（僅主機模式）、VMnet8（NAT模式），那么這些都是有什么作用呢？其實，我們現在看到的VMnet0表示的是用于橋接模式下的虛擬交換機；VMnet1表示的是用于僅主機模式下的虛擬交換機；VMnet8表示的是用于NAT模式下的虛擬交換機。
同時，在主機上對應的有VMware Network Adapter VMnet1和VMware Network Adapter VMnet8兩塊虛擬網卡，它們分別作用于僅主機模式與NAT模式下。在“網絡連接”中我們可以看到這兩塊虛擬網卡，如果將這兩塊卸載了，可以在vmware的“編輯”下的“虛擬網絡編輯器”中點擊“還原默認設置”，可重新將虛擬網卡還原。
小伙伴看到這里，肯定有疑問，為什么在真機上沒有VMware Network Adapter VMnet0虛擬網卡呢？那么接下來，我們就一起來看一下這是為什么。
一、Bridged（橋接模式）
什么是橋接模式？橋接模式就是將主機網卡與虛擬機虛擬的網卡利用虛擬網橋進行通信。在橋接的作用下，類似于把物理主機虛擬為一個交換機，所有橋接設置的虛擬機連接到這個交換機的一個接口上，物理主機也同樣插在這個交換機當中，所以所有橋接下的網卡與網卡都是交換模式的，相互可以訪問而不干擾。在橋接模式下，虛擬機ip地址需要與主機在同一個網段，如果需要聯網，則網關與DNS需要與主機網卡一致。其網絡結構如下圖所示：
接下來，我們就來實際操作，如何設置橋接模式。
首先，安裝完系統之后，在開啟系統之前，點擊“編輯虛擬機設置”來設置網卡模式。
點擊“網絡適配器”，選擇“橋接模式”，然后“確定”
在進入系統之前，我們先確認一下主機的ip地址、網關、DNS等信息。
然后，進入系統編輯網卡配置文件，命令為vi /etc/sysconfig/network-scripts/ifcfg-eth0
添加內容如下：
編輯完成，保存退出，然后重啟虛擬機網卡，使用ping命令ping外網ip，測試能否聯網。
能ping通外網ip，證明橋接模式設置成功。
那主機與虛擬機之間的通信是否正常呢？我們就用遠程工具來測試一下。
主機與虛擬機通信正常。
這就是橋接模式的設置步驟，相信大家應該學會了如何去設置橋接模式了。橋接模式配置簡單，但如果你的網絡環境是ip資源很缺少或對ip管理比較嚴格的話，那橋接模式就不太適用了。如果真是這種情況的話，我們該如何解決呢？接下來，我們就來認識vmware的另一種網絡模式：NAT模式。
二、NAT（地址轉換模式）
剛剛我們說到，如果你的網絡ip資源緊缺，但是你又希望你的虛擬機能夠聯網，這時候NAT模式是最好的選擇。NAT模式借助虛擬NAT設備和虛擬DHCP服務器，使得虛擬機可以聯網。其網絡結構如下圖所示：
在NAT模式中，主機網卡直接與虛擬NAT設備相連，然后虛擬NAT設備與虛擬DHCP服務器一起連接在虛擬交換機VMnet8上，這樣就實現了虛擬機聯網。那么我們會覺得很奇怪，為什么需要虛擬網卡VMware Network Adapter VMnet8呢？原來我們的VMware Network Adapter VMnet8虛擬網卡主要是為了實現主機與虛擬機之間的通信。在之后的設置步驟中，我們可以加以驗證。
首先，設置虛擬機中NAT模式的選項，打開vmware，點擊“編輯”下的“虛擬網絡編輯器”，設置NAT參數及DHCP參數。
將虛擬機的網絡連接模式修改成NAT模式，點擊“編輯虛擬機設置”。
點擊“網絡適配器”，選擇“NAT模式”
然后開機啟動系統，編輯網卡配置文件，命令為vi /etc/sysconfig/network-scripts/ifcfg-eth0
具體配置如下：
編輯完成，保存退出，然后重啟虛擬機網卡，動態獲取ip地址，使用ping命令ping外網ip，測試能否聯網。
之前，我們說過VMware Network Adapter VMnet8虛擬網卡的作用，那我們現在就來測試一下。
如此看來，虛擬機能聯通外網，確實不是通過VMware Network Adapter VMnet8虛擬網卡，那么為什么要有這塊虛擬網卡呢？
之前我們就說VMware Network Adapter VMnet8的作用是主機與虛擬機之間的通信，接下來，我們就用遠程連接工具來測試一下。
然后，將VMware Network Adapter VMnet8啟用之后，發現遠程工具可以連接上虛擬機了。
那么，這就是NAT模式，利用虛擬的NAT設備以及虛擬DHCP服務器來使虛擬機連接外網，而VMware Network Adapter VMnet8虛擬網卡是用來與虛擬機通信的。
三、Host-Only（僅主機模式）
Host-Only模式其實就是NAT模式去除了虛擬NAT設備，然后使用VMware Network Adapter VMnet1虛擬網卡連接VMnet1虛擬交換機來與虛擬機通信的，Host-Only模式將虛擬機與外網隔開，使得虛擬機成為一個獨立的系統，只與主機相互通訊。其網絡結構如下圖所示：
通過上圖，我們可以發現，如果要使得虛擬機能聯網，我們可以將主機網卡共享給VMware Network Adapter VMnet1網卡，從而達到虛擬機聯網的目的。接下來，我們就來測試一下。
首先設置“虛擬網絡編輯器”，可以設置DHCP的起始范圍。
設置虛擬機為Host-Only模式。
開機啟動系統，然后設置網卡文件。
保存退出，然后重啟網卡，利用遠程工具測試能否與主機通信。
主機與虛擬機之間可以通信，現在設置虛擬機聯通外網。
我們可以看到上圖有一個提示，強制將VMware Network Adapter VMnet1的ip設置成192.168.137.1，那么接下來，我們就要將虛擬機的DHCP的子網和起始地址進行修改，點擊“虛擬網絡編輯器”
重新配置網卡，將VMware Network Adapter VMnet1虛擬網卡作為虛擬機的路由。
重啟網卡，然后通過 遠程工具測試能否聯通外網以及與主機通信。
測試結果證明可以使得虛擬機連接外網。
以上就是關于vmware三種網絡模式的工作原理及配置詳解。
Map<String,String> map=new HashMap<String,String>();
map.put("1", "222");
List<Map<String,String>> list = new ArrayList<Map<String,String>>();
list.add(map);
map=null;//沒有效果，list中還是有數據
map.clear();//map沒數據了
Map<String, String> map2 = list.get(0);
System.out.println(map2.size());
System.out.println(map2.get("1"));
背景
通過名字就知道，X-Forwarded-For 是一個 HTTP 擴展頭部。HTTP/1.1（RFC 2616）協議并沒有對它的定義，它最開始是由 Squid 這個緩存代理軟件引入，用來表示 HTTP 請求端真實 IP。如今它已經成為事實上的標準，被各大 HTTP 代理、負載均衡等轉發服務廣泛使用，并被寫入 RFC 7239（Forwarded HTTP Extension）標準之中。
X-Forwarded-For 請求頭格式非常簡單，就這樣：
X-Forwarded-For: client, proxy1, proxy2
可以看到，XFF 的內容由「英文逗號 + 空格」隔開的多個部分組成，最開始的是離服務端最遠的設備 IP，然后是每一級代理設備的 IP。
如果一個 HTTP 請求到達服務器之前，經過了三個代理 Proxy1、Proxy2、Proxy3，IP 分別為 IP1、IP2、IP3，用戶真實 IP 為 IP0，那么按照 XFF 標準，服務端最終會收到以下信息：
X-Forwarded-For: IP0, IP1, IP2
Proxy3 直連服務器，它會給 XFF 追加 IP2，表示它是在幫 Proxy2 轉發請求。列表中并沒有 IP3，IP3 可以在服務端通過 Remote Address 字段獲得。我們知道 HTTP 連接基于 TCP 連接，HTTP 協議中沒有 IP 的概念，Remote Address 來自 TCP 連接，表示與服務端建立 TCP 連接的設備 IP，在這個例子里就是 IP3。
Remote Address 無法偽造，因為建立 TCP 連接需要三次握手，如果偽造了源 IP，無法建立 TCP 連接，更不會有后面的 HTTP 請求。不同語言獲取 Remote Address 的方式不一樣，例如 php 是 $_SERVER["REMOTE_ADDR"]，Node.js 是 req.connection.remoteAddress，但原理都一樣。
問題
有了上面的背景知識，開始說問題。我用 Node.js 寫了一個最簡單的 Web Server 用于測試。HTTP 協議跟語言無關，這里用 Node.js 只是為了方便演示，換成任何其他語言都可以得到相同結論。另外本文用 Nginx 也是一樣的道理，如果有興趣，換成 Apache 或其他 Web Server 也一樣。
下面這段代碼會監聽 9009 端口，并在收到 HTTP 請求后，輸出一些信息：
JSvar http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.write('remoteAddress: ' + req.connection.remoteAddress + '\n'); res.write('x-forwarded-for: ' + req.headers['x-forwarded-for'] + '\n'); res.write('x-real-ip: ' + req.headers['x-real-ip'] + '\n'); res.end(); }).listen(9009, '0.0.0.0');
這段代碼除了前面介紹過的 Remote Address 和 X-Forwarded-For，還有一個 X-Real-IP，這又是一個自定義頭部字段。X-Real-IP 通常被 HTTP 代理用來表示與它產生 TCP 連接的設備 IP，這個設備可能是其他代理，也可能是真正的請求端。需要注意的是，X-Real-IP 目前并不屬于任何標準，代理和 Web 應用之間可以約定用任何自定義頭來傳遞這個信息。
現在可以用域名 + 端口號直接訪問這個 Node.js 服務，再配一個 Nginx 反向代理：
NGINXlocation / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass http://127.0.0.1:9009/; proxy_redirect off; }
我的 Nginx 監聽 80 端口，所以不帶端口就可以訪問 Nginx 轉發過的服務。
測試直接訪問 Node 服務：
BASHcurl http://t1.imququ.com:9009/ remoteAddress: 114.248.238.236 x-forwarded-for: undefined x-real-ip: undefined
由于我的電腦直接連接了 Node.js 服務，Remote Address 就是我的 IP。同時我并未指定額外的自定義頭，所以后兩個字段都是 undefined。
再來訪問 Nginx 轉發過的服務：
BASHcurl http://t1.imququ.com/ remoteAddress: 127.0.0.1 x-forwarded-for: 114.248.238.236 x-real-ip: 114.248.238.236
這一次，我的電腦是通過 Nginx 訪問 Node.js 服務，得到的 Remote Address 實際上是 Nginx 的本地 IP。而前面 Nginx 配置中的這兩行起作用了，為請求額外增加了兩個自定義頭：
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
實際上，在生產環境中部署 Web 應用，一般都采用上面第二種方式，有很多好處。但這就引入一個隱患：很多 Web 應用為了獲取用戶真正的 IP，從 HTTP 請求頭中獲取 IP。
HTTP 請求頭可以隨意構造，我們通過 curl 的 -H 參數構造 X-Forwarded-For 和 X-Real-IP，再來測試一把。
直接訪問 Node.js 服務：
BASHcurl http://t1.imququ.com:9009/ -H 'X-Forwarded-For: 1.1.1.1' -H 'X-Real-IP: 2.2.2.2' remoteAddress: 114.248.238.236 x-forwarded-for: 1.1.1.1 x-real-ip: 2.2.2.2
對于 Web 應用來說，X-Forwarded-For 和 X-Real-IP 就是兩個普通的請求頭，自然就不做任何處理原樣輸出了。這說明，對于直連部署方式，除了從 TCP 連接中得到的 Remote Address 之外，請求頭中攜帶的 IP 信息都不能信。
訪問 Nginx 轉發過的服務：
BASHcurl http://t1.imququ.com/ -H 'X-Forwarded-For: 1.1.1.1' -H 'X-Real-IP: 2.2.2.2' remoteAddress: 127.0.0.1 x-forwarded-for: 1.1.1.1, 114.248.238.236 x-real-ip: 114.248.238.236
這一次，Nginx 會在 X-Forwarded-For 后追加我的 IP；并用我的 IP 覆蓋 X-Real-IP 請求頭。這說明，有了 Nginx 的加工，X-Forwarded-For 最后一節以及 X-Real-IP 整個內容無法構造，可以用于獲取用戶 IP。
用戶 IP 往往會被使用與跟 Web 安全有關的場景上，例如檢查用戶登錄地區，基于 IP 做訪問頻率控制等等。這種場景下，確保 IP 無法構造更重要。經過前面的測試和分析，對于直接面向用戶部署的 Web 應用，必須使用從 TCP 連接中得到的 Remote Address；對于部署了 Nginx 這樣反向代理的 Web 應用，在正確配置了 Set Header 行為后，可以使用 Nginx 傳過來的 X-Real-IP 或 X-Forwarded-For 最后一節（實際上它們一定等價）。
那么，Web 應用自身如何判斷請求是直接過來，還是由可控的代理轉發來的呢？在代理轉發時增加額外的請求頭是一個辦法，但是不怎么保險，因為請求頭太容易構造了。如果一定要這么用，這個自定義頭要夠長夠罕見，還要保管好不能泄露出去。
判斷 Remote Address 是不是本地 IP 也是一種辦法，不過也不完善，因為在 Nginx 所處服務器上訪問，無論直連還是走 Nginx 代理，Remote Address 都是 127.0.0.1。這個問題還好通常可以忽略，更麻煩的是，反向代理服務器和實際的 Web 應用不一定部署在同一臺服務器上。所以更合理的做法是收集所有代理服務器 IP 列表，Web 應用拿到 Remote Address 后逐一比對來判斷是以何種方式訪問。
通常，為了簡化邏輯，生產環境會封掉通過帶端口直接訪問 Web 應用的形式，只允許通過 Nginx 來訪問。那是不是這樣就沒問題了呢？也不見得。
首先，如果用戶真的是通過代理訪問 Nginx，X-Forwarded-For 最后一節以及 X-Real-IP 得到的是代理的 IP，安全相關的場景只能用這個，但有些場景如根據 IP 顯示所在地天氣，就需要盡可能獲得用戶真實 IP，這時候 X-Forwarded-For 中第一個 IP 就可以排上用場了。這時候需要注意一個問題，還是拿之前的例子做測試：
BASHcurl http://t1.imququ.com/ -H 'X-Forwarded-For: unknown, <>"1.1.1.1' remoteAddress: 127.0.0.1 x-forwarded-for: unknown, <>"1.1.1.1, 114.248.238.236 x-real-ip: 114.248.238.236
X-Forwarded-For 最后一節是 Nginx 追加上去的，但之前部分都來自于 Nginx 收到的請求頭，這部分用戶輸入內容完全不可信。使用時需要格外小心，符合 IP 格式才能使用，不然容易引發 SQL 注入或 XSS 等安全漏洞。
結論
- 直接對外提供服務的 Web 應用，在進行與安全有關的操作時，只能通過 Remote Address 獲取 IP，不能相信任何請求頭；
- 使用 Nginx 等 Web Server 進行反向代理的 Web 應用，在配置正確的前提下，要用
X-Forwarded-For 最后一節 或 X-Real-IP 來獲取 IP（因為 Remote Address 得到的是 Nginx 所在服務器的內網 IP）；同時還應該禁止 Web 應用直接對外提供服務； - 在與安全無關的場景，例如通過 IP 顯示所在地天氣，可以從
X-Forwarded-For 靠前的位置獲取 IP，但是需要校驗 IP 格式合法性；
PS：網上有些文章建議這樣配置 Nginx，其實并不合理：
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr;
這樣配置之后，安全性確實提高了，但是也導致請求到達 Nginx 之前的所有代理信息都被抹掉，無法為真正使用代理的用戶提供更好的服務。還是應該弄明白這中間的原理，具體場景具體分析。
proxy_intercept_errors on; #如果被代理服務器返回的狀態碼為400或者大于400，設置的error_page配置起作用。默認為off。
error_page 404 https://www.baidu.com; #錯誤頁
如果我們的代理只允許接受get，post請求方法的一種
proxy_method get; #支持客戶端的請求方法。post/get；
如果你的nginx服務器給2臺web服務器做代理，負載均衡算法采用輪詢，那么當你的一臺機器web程序iis關閉，也就是說web不能訪問，那么nginx服務器分發請求還是會給這臺不能訪問的web服務器，如果這里的響應連接時間過長，就會導致客戶端的頁面一直在等待響應，對用戶來說體驗就打打折扣，這里我們怎么避免這樣的情況發生呢。這里我配張圖來說明下問題。
如果負載均衡中其中web2發生這樣的情況，nginx首先會去web1請求，但是nginx在配置不當的情況下會繼續分發請求道web2，然后等待web2響應，直到我們的響應時間超時，才會把請求重新分發給web1，這里的響應時間如果過長，用戶等待的時間就會越長。
下面的配置是解決方案之一。
proxy_connect_timeout 1; #nginx服務器與被代理的服務器建立連接的超時時間，默認60秒
proxy_read_timeout 1; #nginx服務器想被代理服務器組發出read請求后，等待響應的超時間，默認為60秒。
proxy_send_timeout 1; #nginx服務器想被代理服務器組發出write請求后，等待響應的超時間，默認為60秒。
proxy_ignore_client_abort on; #客戶端斷網時，nginx服務器是否終端對被代理服務器的請求。默認為off。