一、單例模式(Singleton): 保證一個類僅有一個實例,並提供一個訪問它的全局控制點,好比在加載配置文件時, 可以使用該模式.java
二、工廠模式(Factory): 定義一個用以建立對象的接口, 讓子類決定實例化哪一個類.web
三、裝飾着模式(Decorator): 動態的給一個對象添加一些額外的職責.面試
好比java.io包. BufferedInputStream封裝了FileInputStream, 它們都實現了InputStream接口, 但前者實現了readLine方法.算法
四、代理模式(Proxy): 爲其餘對象提供一種代理以控制對這個對象的訪問.spring
好比在用戶登陸時, 真正的登陸類和代理登陸類都實現了Login接口, 不一樣的是Proxy類的方法中增長了用戶是否合法的判斷, 只有合法時纔去調用真正登陸類的login方法. 用戶訪問 的實際上是Proxy的login方法.數據庫
五、觀察者模式(Observer): 定義了一種一對多的依賴關係,讓多個觀察者對象同時監聽某一主題對象,在它的狀態發生變化時,會通知全部的觀察者.編程
好比ServletContextListener, 在applcation啓動時, 會通知全部這個接口的實現類.設計模式
單例模式三要點: 數組
(1)、單例類只能有一個實例瀏覽器
這是最基本的,真正作到整個系統中惟一併不容易,一般還要考慮反射破壞、序列化/反序列化、對象垃圾回收等問題。
(2)、單例類必須本身建立本身的惟一實例
一般給實例構造函數protected或private權限。
(3)、單例類必須給全部其餘對象提供這一實例
一般定義靜態方法getInstance()返回。
優勢:
(1)、提供了對惟一實例的受控訪問,避免對資源的多重佔用。
(2)、在內存裏只有一個實例,減小了內存的開銷,尤爲是頻繁的建立和銷燬實例。
(3)、縮小名空間,避免全局變量污染空間,但比類操做更靈活。
缺點:
(1)、因爲單例模式中沒有抽象層,所以單例類的擴展有很大的困難。
(2)、 單例類的職責太重,在必定程度上違背了"單一職責原則"。
由於單例類既充當了工廠角色,提供了工廠方法,同時又充當了產品角色,包含一些業務方法,將產品的建立和產品的自己的功能融合到一塊兒。因此也不該過多使用單例模式。
優勢
1.使用Spring的IOC容器,將對象之間的依賴關係交給Spring,下降組件之間的耦合性,讓咱們更專一於應用邏輯
2.能夠提供衆多服務,事務管理,WS等。
3.AOP的很好支持,方便麪向切面編程。
4.對主流的框架提供了很好的集成支持,如hibernate,Struts2,JPA等
5.Spring DI機制下降了業務對象替換的複雜性。
6.Spring屬於低侵入,代碼污染極低。
7.Spring的高度可開放性,並不強制依賴於Spring,開發者能夠自由選擇Spring部分或所有
缺點
1.jsp中要寫不少代碼、控制器過於靈活,缺乏一個公用控制器
2.Spring不支持分佈式,這也是EJB仍然在用的緣由之一。
答:
(1)TCP/IP有4層;
(2)應用層、傳輸層、網絡層、數據鏈路層;
(3)傳輸層有TCP和UDP協議
(4)HTTP協議基於TCP協議
由HTTP客戶端發起一個請求,創建一個到服務器指定端口(默認是80端口)的TCP鏈接。
HTTP服務器則在那個端口監聽客戶端發送過來的請求。
一旦收到請求,服務器(向客戶端)發回一個狀態行和(響應的)消息,消息的消息體多是請求的文件、錯誤消息、或者其它一些信息。
HTTP使用TCP而不是UDP的緣由在於(打開)一個網頁必須傳送不少數據,而TCP協議提供傳輸控制,按順序組織數據,和錯誤糾正。
https協議須要到ca申請證書,通常免費證書不多,須要交費。
http是超文本傳輸協議,信息是明文傳輸,https 則是具備安全性的ssl加密傳輸協議。
http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。
http的鏈接很簡單,是無狀態的。
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全。
HTTPS解決的問題:
1、HTTP和HTTPS的基本概念
HTTP:是互聯網上應用最爲普遍的一種網絡協議,是一個客戶端和服務器端請求和應答的標準(TCP),用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議,它能夠使瀏覽器更加高效,使網絡傳輸減小。
HTTPS:是以安全爲目標的HTTP通道,簡單講是HTTP的安全版,即HTTP下加入SSL層,HTTPS的安全基礎是SSL,所以加密的詳細內容就須要SSL。
HTTPS協議的主要做用能夠分爲兩種:一種是創建一個信息安全通道,來保證數據傳輸的安全;另外一種就是確認網站的真實性。
2、HTTP與HTTPS有什麼區別?
HTTP協議傳輸的數據都是未加密的,也就是明文的,所以使用HTTP協議傳輸隱私信息很是不安全,爲了保證這些隱私數據能加密傳輸,因而網景公司設計了SSL(Secure Sockets Layer)協議用於對HTTP協議傳輸的數據進行加密,從而就誕生了HTTPS。
簡單來講,HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,要比http協議安全。
HTTPS和HTTP的區別主要以下:
一、https協議須要到ca申請證書,通常免費證書較少,於是須要必定費用。
二、http是超文本傳輸協議,信息是明文傳輸,https則是具備安全性的ssl加密傳輸協議。
三、http和https使用的是徹底不一樣的鏈接方式,用的端口也不同,前者是80,後者是443。
四、http的鏈接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。
3、HTTPS的工做原理
咱們都知道HTTPS可以加密信息,以避免敏感信息被第三方獲取,因此不少銀行網站或電子郵箱等等安全級別較高的服務都會採用HTTPS協議。
一、客戶端發起HTTPS請求
這個沒什麼好說的,就是用戶在瀏覽器裏輸入一個https網址,而後鏈接到server的443端口。
二、服務端的配置
採用HTTPS協議的服務器必需要有一套數字證書,能夠本身製做,也能夠向組織申請,區別就是本身頒發的證書須要客戶端驗證經過,才能夠繼續訪問,而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇,有1年的免費服務)。
這套證書其實就是一對公鑰和私鑰,若是對公鑰和私鑰不太理解,能夠想象成一把鑰匙和一個鎖頭,只是全世界只有你一我的有這把鑰匙,你能夠把鎖頭給別人,別人能夠用這個鎖把重要的東西鎖起來,而後發給你,由於只有你一我的有這把鑰匙,因此只有你才能看到被這把鎖鎖起來的東西。
三、傳送證書
這個證書其實就是公鑰,只是包含了不少信息,如證書的頒發機構,過時時間等等。
四、客戶端解析證書
這部分工做是有客戶端的TLS來完成的,首先會驗證公鑰是否有效,好比頒發機構,過時時間等等,若是發現異常,則會彈出一個警告框,提示證書存在問題。
若是證書沒有問題,那麼就生成一個隨機值,而後用證書對該隨機值進行加密,就好像上面說的,把隨機值用鎖頭鎖起來,這樣除非有鑰匙,否則看不到被鎖住的內容。
五、傳送加密信息
這部分傳送的是用證書加密後的隨機值,目的就是讓服務端獲得這個隨機值,之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。
六、服務段解密信息
服務端用私鑰解密後,獲得了客戶端傳過來的隨機值(私鑰),而後把內容經過該值進行對稱加密,所謂對稱加密就是,將信息和私鑰經過某種算法混合在一塊兒,這樣除非知道私鑰,否則沒法獲取內容,而正好客戶端和服務端都知道這個私鑰,因此只要加密算法夠彪悍,私鑰夠複雜,數據就夠安全。
七、傳輸加密後的信息
這部分信息是服務段用私鑰加密後的信息,能夠在客戶端被還原。
八、客戶端解密信息
客戶端用以前生成的私鑰解密服務段傳過來的信息,因而獲取瞭解密後的內容,整個過程第三方即便監聽到了數據,也一籌莫展。
6、HTTPS的優勢
正是因爲HTTPS很是的安全,攻擊者沒法從中找到下手的地方,從站長的角度來講,HTTPS的優勢有如下2點:
一、SEO方面
谷歌曾在2014年8月份調整搜索引擎算法,並稱「比起同等HTTP網站,採用HTTPS加密的網站在搜索結果中的排名將會更高」。
二、安全性
儘管HTTPS並不是絕對安全,掌握根證書的機構、掌握加密算法的組織一樣能夠進行中間人形式的攻擊,但HTTPS還是現行架構下最安全的解決方案,主要有如下幾個好處:
(1)、使用HTTPS協議可認證用戶和服務器,確保數據發送到正確的客戶機和服務器;
(2)、HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,要比http協議安全,可防止數據在傳輸過程當中不被竊取、改變,確保數據的完整性。
(3)、HTTPS是現行架構下最安全的解決方案,雖然不是絕對安全,但它大幅增長了中間人攻擊的成本。
7、HTTPS的缺點
雖說HTTPS有很大的優點,但其相對來講,仍是有些不足之處的,具體來講,有如下2點:
一、SEO方面
據ACM CoNEXT數據顯示,使用HTTPS協議會使頁面的加載時間延長近50%,增長10%到20%的耗電,此外,HTTPS協議還會影響緩存,增長數據開銷和功耗,甚至已有安全措施也會受到影響也會所以而受到影響。
並且HTTPS協議的加密範圍也比較有限,在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用。
最關鍵的,SSL證書的信用鏈體系並不安全,特別是在某些國家能夠控制CA根證書的狀況下,中間人攻擊同樣可行。
二、經濟方面
(1)、SSL證書須要錢,功能越強大的證書費用越高,我的網站、小網站沒有必要通常不會用。
(2)、SSL證書一般須要綁定IP,不能在同一IP上綁定多個域名,IPv4資源不可能支撐這個消耗(SSL有擴展能夠部分解決這個問題,可是比較麻煩,並且要求瀏覽器、操做系統支持,Windows XP就不支持這個擴展,考慮到XP的裝機量,這個特性幾乎沒用)。
(3)、HTTPS鏈接緩存不如HTTP高效,大流量網站如非必要也不會採用,流量成本過高。
(4)、HTTPS鏈接服務器端資源佔用高不少,支持訪客稍多的網站須要投入更大的成本,若是所有采用HTTPS,基於大部分計算資源閒置的假設的VPS的平均成本會上去。
(5)、HTTPS協議握手階段比較費時,對網站的相應速度有負面影響,如非必要,沒有理由犧牲用戶體驗。
(1)Cookie的原理是經過Set-Cookie響應頭和Cookie請求頭將會話中產生的數據保存在客戶端
Set-Cookie
Cookie
客戶端請求服務器, 服務器將須要保存的數據經過Set-Cookie響應頭髮給客戶端, 客戶端收到後會將數據保存在瀏覽器的內部
當客戶端再次請求服務器時, 經過Cookie請求頭將上次保存的數據再帶給服務器, 服務器經過Cookie頭來獲取數據, 經過這種方式能夠保存會話中產生的數據.
Cookie是將須要保存的數據保存在了客戶端, 是客戶端技術. 每一個客戶端各自保存各自的數據, 再次訪問服務器時會帶着本身的數據, 每一個客戶端持有本身的數據, 所以就不會發生混
了
(2)Session是將會話中產生的數據保存在了服務器端, 是服務器端技術
Session是一個域對象
setAttribute(String name, Object value);
getAttribute(String name);
removeAttribute(String name)
getAttributeNames()
生命週期:
當第一次調用request.getSession()方法時建立Session
超時: 若是一個Session超時30分鐘(能夠在web.xml中來修改, 在根目錄下經過<session-config>來配置)未被使用, 則認爲Session超時, 銷燬session
自殺: 當調用session.invalidate()方法的時session當即銷燬!!
意外身亡: 當服務器非正常關閉時, 隨着應用的銷燬, session銷燬. 當服務器正常關閉, 則未超時的session將會以文件的形式保存在tomcat服務器work目錄下, 這個過程叫作
session的鈍化. 當服務器再次啓動時, 鈍化着的session還能夠恢復過來, 這個過程叫作session的活化。
做用範圍: 當前會話範圍
主要功能: 保存當前會話相關的數據
Session是基於一個JSESSIOINID的Cookie工做的
(3)Cookie和Session的比較:
Cookie是將會話中產生的數據保存在客戶端, 是客戶端的技術
Session是將會話中產生的數據保存在服務器端, 是服務器端的技術
Cookie保存的信息的時間比較長, 可是安全性不高. 可能隨着用戶的操做, Cookie會被清空, 因此Cookie存儲數據的穩定性比較差. 所以Cookie適合存放要保存時間較長, 但安全性要求
不高的信息
Session一般保存信息的時間比較有限, 但安全性比較高, 由於是保存在服務器端, 不會隨着用戶的操做而致使Session意外丟失, 所以session適合存放安全性要求比較高, 可是不須要
長時間保存的數據.
一、客戶端發出一個http請求給web服務器,web服務器對http請求進行解析,若是匹配DispatcherServlet的請求映射路徑(在web.xml中指定),web容器將請求轉交給DispatcherServlet.
二、DipatcherServlet接收到這個請求以後將根據請求的信息(包括URL、Http方法、請求報文頭和請求參數Cookie等)以及HandlerMapping的配置找處處理請求的處理器(Handler)。
3-四、DispatcherServlet根據HandlerMapping找到對應的Handler,將處理權交給Handler(Handler將具體的處理進行封裝),再由具體的HandlerAdapter對Handler進行具體的調用。
五、Handler對數據處理完成之後將返回一個ModelAndView()對象給DispatcherServlet。
六、Handler返回的ModelAndView()只是一個邏輯視圖並非一個正式的視圖,DispatcherSevlet經過ViewResolver將邏輯視圖轉化爲真正的視圖View。
七、Dispatcher經過model解析出ModelAndView()中的參數進行解析最終展示出完整的view並返回給客戶端。
1.封裝
Java中的封裝是指一個類把本身內部的實現細節進行隱藏,只暴露對外的接口(setter和getter方法)。封裝又分爲屬性的封裝和方法的封裝。把屬性定義爲私有的,它們經過setter和getter方法來對屬性的值進行設定和獲取。下面我舉一個簡單的封裝例子
public class Person { private int id; private String name; private Person person; public int getId() { return id; } public String getName() { return name; } public Person getPerson() { return person; } public void setId(int id) { this.id = id; } public void setName(String name) { this.name = name; } public void setPerson(Person person) { this.person = person; } }
在Person類中,定義了三個成員變量,分別爲id name person,它們的訪問修飾都是private私有的,經過setter和getter方法對這些變量進行設值以及取值。那麼這麼作有什麼好處呢?封裝的意義就是加強類的信息隱藏與模塊化,提升安全性。封裝的主要做用也是對外部隱藏具體的實現細節,增長程序的安全性。
2.繼承
Java中的繼承是指在一個現有類(父類)的基礎上在構建一個新類(子類),子類能夠擁有父類的成員變量以及成員方法(可是不必定能訪問或調用,例如父類中private私有的成員變量以及方法不能訪問和調用)。繼承的做用就是能提升代碼的複用性。子類擁有父類中的一切(擁有不必定能使用),它能夠訪問和使用父類中的非私有成員變量,以及重寫父類中的非私有成員方法。
父類:
package cn.csu.ksh; public class Person { private int a=1;//父類私有成員變量 private int id; private String name; private int age; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } @Override public String toString() { return "Person [id=" + id + ", name=" + name + ", age=" + age + "]"; } public void say() { System.out.println("person say.."); } public void run() { System.out.println("person run...."); } //父類的私有方法 private void show() { System.out.println("person show..."); } }
子類:
public class Student extends Person { @Override public void say() { super.say(); } @Override public void run() { super.run(); } public static void main(String[] args) { Student stu = new Student(); //stu.a=1;//子類對象對父類的私有成員變量使用報錯! //stu.show();//子類對象調用父類的私有方法,一樣報錯! stu.say(); stu.run(); } }
繼承的好處是實現代碼的複用以及擴展,子類經過對父類代碼的複用,能夠不用再定義父類中已經定義的成員變量,方法上直接對父類的方法進行重寫實現了擴展。
3.多態
多態就是指多種狀態,就是說當一個操做在不一樣的對象時,會產生不一樣的結果。
在Java中,實現多態的方式有兩種,一種是編譯時的多態,另一種是運行時多態,編譯時的多態是經過方法的重載實現的,而運行時多態是經過方法的重寫實現的。
方法的重載是指在同一個類中,有多個方法名相同的方法,可是這些方法有着不一樣的參數列表,在編譯期咱們就能夠肯定到底調用哪一個方法。
方法的重寫,子類重寫父類中的方法(包括接口的實現),父類的引用不只能夠指向父類的對象,並且還能夠指向子類的對象。當父類的引用指向子類的引用時,只有在運行時才能
肯定調用哪一個方法。
其實在運行時的多態的實現,須要知足三個條件:1.繼承(包括接口的實現)2.方法的重寫 3.父類的引用指向子類對象
而且,咱們說的多態都是類中方法的多態,屬性是沒有多態性的。方法的重載我這裏就不舉例說明了,我說一下運行時的多態。
一,Conllection:
Collection接口:
他有兩個子接口,Set和List,
1,Set(公共特色;無序)
是一個無序的集合接口,而且元素不可重複,固然,這裏的無序是針對放入順序而言,並非絕對的無序,他有兩個子類,一個是hashSet,還有一個是繼承了SortedSet接口的
TreeSet,這兩個set集合有什麼特色呢?
首先,hashSet的底層是hashmap,他有着hashmap中鍵的特性,那就是,無序,不可重複性,
其次,treeset實現了sortset接口,sortedset有排序能力,也就意味着treeset也有着排序的能力,他是使用二叉樹進行排序的。
2,list(有序):
list接口也有兩個子類,一個是arraylist,一個是linkedList,
首先arralist的底層是object[]是一個數組,也就意味着他有着數組的特性,可是和數組相比他比數組靈活,無需設置長度,他是有序的,因此查找塊,增刪比較慢,
和arralist其實有一個兄弟叫vector,他和arralist是同樣的
Vector是線程安全的,也就是說是它的方法之間是線程同步的,而arralist線程是異步的也就是說他是不安全的,可是效率高,相比之下,建議使用arralist.,
linkedlist:
他底層是以鏈表的形式進行排序的,兩個元素之間就如同鏈子同樣前關聯,若是進行增刪操做的時候,只須要將某個元素替換而後將後邊的關聯簡單修改就能夠完成,因此說建議查
詢用arralist,增刪用linkedlist;
二,map(公共特色特色:以鍵值對的形式存儲,):
簡單來說經常使用的map類的集合也有三個,經常使用的有三個子類實現了mapj接口:map存在的意義就是爲了快速查找,經過鍵的直接找到值,由於鍵是不可重複的。
1,hashMap和hashtable:
二者放在一塊兒比較(底層都是hash表結構):hashmap線程是不安全的容許鍵值對爲null,二hashtable線程是安全的不容許鍵值對爲null,二者的其餘屬性是同樣的,因此二者的使
用要看具體的狀況而定,
2,treemap(底層是二叉樹)
線程不一樣步,可用於給Map集合中的鍵進行排序
雖說有些集合是無序的,可是子類個別的也是按照另外一種方式進行了排序,只不過不符合咱們平常的排序方式。是按照某種規則進行的。
總結:三者的存在關係:
Map中元素,能夠將key序列、value序列單獨抽取出來。
使用keySet()抽取key序列,將map中的全部keys生成一個Set。
使用values()抽取value序列,將map中的全部values生成一個Collection。
爲何一個生成Set,一個生成Collection?那是由於,key老是獨一無二的,value容許重複
捕獲異常:
一般在運行以前java不報錯,可是運行後可能會出現某些未知的錯誤,可是還不想直接拋出到上一級,
那麼就須要經過」try{}catch「的形式進行異常捕獲,以後根據不一樣的異常狀況來進行相應的處理。
傳遞異常:
一般用在多級方法調用上,最終想將異常返回到最上層進行處理的時候,那麼就把異常向上拋出,知道調用的方法處,進行異常捕獲。
異常拋出:
運行時異常會被Java虛擬機自動拋出!
提前拋出:
有些比較明確的異常須要提早拋出,這樣咱們能夠經過控制檯打印的異常信息快速定位到出錯的代碼塊,同時也能夠避免沒必要要的對象構造或者資源調用。
以下分別在調用兩個方法的時候fileName參數都傳遞爲null,顯然採用代碼二的方式更有利排查錯誤。
延遲捕獲:讓異常捕獲處理放在最外層進行處理,這樣才能根據不一樣的狀況進行不一樣的處理。
Throwable是全部異常的根,java.lang.Throwable
Error:錯誤,Java.lang.Error
Exception:異常,java.lang.Exception
運行時異常:
都是RuntimeException類及其子類異常,如NullPointerException(空指針異常)、IndexOutOfBoundsException(下標越界異常)等,這些異常是不檢查異常,程序中能夠選擇捕獲處理,也能夠不處理。這些異常通常是由程序邏輯錯誤引發的,程序應該從邏輯角度儘量避免這類異常的發生。
運行時異常的特色是Java編譯器不會檢查它,也就是說,當程序中可能出現這類異常,即便沒有用try-catch語句捕獲它,也沒有用throws子句聲明拋出它,也會編譯經過。
非運行時異常 (編譯異常):
是RuntimeException之外的異常,類型上都屬於Exception類及其子類。從程序語法角度講是必須進行處理的異常,若是不處理,程序就不能編譯經過。
如IOException、SQLException等以及用戶自定義的Exception異常,通常狀況下不自定義檢查異常。
ClassCastException(類轉換異常)
IndexOutOfBoundsException(數組越界異常)
NullPointerException(空指針異常)
ArrayStoreException(數據存儲異常,操做數組時類型不一致)
BufferOverflowException(還有IO操做的,緩衝溢出異常)
其實jvm能優化的空間很少,最主要的是使用的共享內存不要超過默認的2g或者本身調的參數。但瞭解一下仍是有點意思的,建議面試時仍是要看,別學筆者裸奔。
網上說是有5點區別。但筆者認爲只有兩點主要區別。
堆--用new創建,垃圾自動回收負責回收
一、堆是一個"運行時"數據區,類實例化的對象就是從堆上去分配空間的;
二、在堆上分配空間是經過"new"等指令創建的;
三、Java針對堆的操做和C++的區別就是,Java不須要在空間不用的時候來顯式的釋放;
四、Java的堆是由Java的垃圾回收機制來負責處理的,堆是動態分配內存大小,垃圾收集器能夠自動回收再也不使用的內存空間。
五、但缺點是,由於在運行時動態分配內存,因此內存的存取速度較慢。
一、棧中主要存放一些基本類型的變量(int, short, long, byte, float, double, boolean, char)和對象句柄;
二、棧的存取速度比堆要快;
三、棧數據能夠共享;
四、棧的數據大小與生存期必須是肯定的,缺少靈活性。
筆者認爲就兩點:
(1)堆主要放new的對象,而棧放基本類型和句柄,句柄指向的是堆。
(2)垃圾回收的時候回收的是堆,棧比較難回收,通常不回收(這個纔是問你的緣由,呵呵)。
就速度而言,都是內存操做,其實並無很大區別。
https://blog.csdn.net/album_gyd/article/details/81369154
類是面向對象中的一個很重要的概念,由於類是不少個具備相同屬性和行爲特徵的對象所抽象出來的,對象是類的一個實例。
而後,圍繞類的三個特徵來講了:封裝、繼承和多態。
一、封裝:面嚮對象語言的精髓
把一些屬性和方法封裝起來,造成一個類;
類的屬性通常私有;
類的方法:該公開的公開,該私有的私有;方法,封裝了實現的過程,接口是參數和返回值;
舉例:
1)get/set 方法;對某一個屬性只提供get不提供set方法,就是隻讀的,在類的外部不能修改;
2)提供統一的參數檢查,在set上給與檢查,判斷合法性和安全性;將屬性都私有,而且提供set/get 方法,作成了通用的組件,叫JavaBean;
2. 繼承:面向對象的主要功能
繼承是一種構建新類的方式,他是基於已有的類的定義爲基礎,構建新的類,已有的類稱爲父類,新構建的類稱爲子類,子類能調用父類的非private修飾的成員,
同時還能夠本身添加一些新的成員,擴充父類,甚至重寫父類已有的方法,更其表現符合子類的特徵。讓子類的表現更獨特,更專業。
3.多態
從必定角度來看,封裝和繼承幾乎都是爲多態而準備的。這是咱們最後一個概念,也是最重要的知識點。
多態是同一個行爲具備多個不一樣表現形式或形態的能力。多態性是對象多種表現形式的體現
類中多個方法的重載叫多態,父子類中方法的覆蓋也叫多態。
所以多態有兩種體現:一個是方法的重裝,一個是方法的覆蓋。
多態有方法的多態和對象的多態(一個對象多種形態)。
具體來講cookie機制採用的是在客戶端保持狀態的方案,而session機制採用的是在服務器端保持狀態的方案。
同時咱們也看到,因爲才服務器端保持狀態的方案在客戶端也須要保存一個標識,因此session
機制可能須要藉助於cookie機制來達到保存標識的目的,但實際上還有其餘選擇
若是不設置過時時間,則表示這個cookie生命週期爲瀏覽器會話期間,只要關閉瀏覽器窗口,cookie就消失了。這種生命期爲瀏覽會話期的cookie被稱爲會話cookie。
會話cookie通常不保存在硬盤上而是保存在內存裏。
若是設置了過時時間,瀏覽器就會把cookie保存到硬盤上,關閉後再次打開瀏覽器,這些cookie依然有效直到超過設定的過時時間。
存儲在硬盤上的cookie能夠在不一樣的瀏覽器進程間共享,好比兩個IE窗口。而對於保存在內存的cookie,不一樣的瀏覽器有不一樣的處理方式。
當用戶在某個網站註冊後,就會收到一個唯一用戶ID的cookie。客戶後來從新鏈接時,
這個用戶ID會自動返回,服務器對它進行檢查,肯定它是否爲註冊用戶且選擇了自動登陸,從而使用戶務需給出明確的用戶名和密碼,就能夠訪問服務器上的資源。
網站能夠使用cookie記錄用戶的意願。對於簡單的設置,網站能夠直接將頁面的設置存儲在cookie中完成定製。然而對於更復雜的定製,網站只需僅將一個唯一的標識符發送給用戶,由服務器端的數據庫存儲每一個標識符對應的頁面設置。
1.建立Cookie對象
2.設置最大時效
3.將Cookie放入到HTTP響應報頭
若是你建立了一個cookie,並將他發送到瀏覽器,默認狀況下它是一個會話級別的cookie:存儲在瀏覽器的內存中,用戶退出瀏覽器以後被刪除。若是你但願瀏覽器將該cookie存儲在磁盤上,則
須要使用maxAge,並給出一個以秒爲單位的時間。將最大時效設爲0則是命令瀏覽器刪除該cookie。
發送cookie須要使用HttpServletResponse的addCookie方法,將cookie插入到一個Set-Cookie HTTP請求報頭中。因爲這個方法並不修改任何以前指定的Set-Cookie報頭,而是建立新的報頭,所以咱們將這個方法稱爲是addCookie,而非setCookie。一樣要記住響應報頭必須在任何文檔內容發送到客戶端以前設置。
1.調用request.getCookie
要獲取有瀏覽器發送來的cookie,須要調用HttpServletRequest的getCookies方法,這個調用返回Cookie對象的數組,對應由HTTP請求中Cookie報頭輸入的值。
2.對數組進行循環,調用每一個cookie的getName方法,直到找到感興趣的cookie爲止
cookie與你的主機(域)相關,而非你的servlet或JSP頁面。於是,儘管你的servlet可能只發送了單個cookie,你也可能會獲得許多不相關的cookie。
例如:
String cookieName = 「userID」; Cookie cookies[] = request.getCookies(); if (cookies!=null){ for(int i=0;i<cookies.length;i++){ Cookie cookie = cookies[i]; if (cookieName.equals(cookie.getName())){ doSomethingWith(cookie.getValue()); } } }
A.調用HttpServletRequest.getCookies()獲取Cookie數組
B.在循環中檢索指定名字的cookie是否存在以及對應的值是否正確
C.若是是則退出循環並設置區別標識
D.根據區別標識判斷用戶是否爲初訪者從而進行不一樣的操做
不能僅僅由於cookie數組中不存在在特定的數據項就認爲用戶是個初訪者。若是cookie數組爲null,客戶多是一個初訪者,也多是因爲用戶將cookie刪除或禁用形成的結果。
可是,若是數組非null,也不過是顯示客戶曾經到過你的網站或域,並不能說明他們曾經訪問過你的servlet。其它servlet、JSP頁面以及非Java Web應用均可以設置cookie,依據路徑的設置,其中的任何cookie都有可能返回給用戶的瀏覽器。
正確的作法是判斷cookie數組是否爲空且是否存在指定的Cookie對象且值正確。
屬性是從服務器發送到瀏覽器的報頭的一部分;但它們不屬於由瀏覽器返回給服務器的報頭。
所以除了名稱和值以外,cookie屬性只適用於從服務器輸出到客戶端的cookie;服務器端來自於瀏覽器的cookie並無設置這些屬性。
於是不要指望經過request.getCookies獲得的cookie中能夠使用這個屬性。這意味着,你不能僅僅經過設置cookie的最大時效,發出它,在隨後的輸入數組中查找適當的cookie,讀取它的值,修改它並將它存回Cookie,從而實現不斷改變的cookie值。
1.獲取cookie數組中專門用於統計用戶訪問次數的cookie的值
2.將值轉換成int型
3.將值加1並用原來的名稱從新建立一個Cookie對象
4.從新設置最大時效
5.將新的cookie輸出
session,中文常常翻譯爲會話,其原本的含義是指善始善終的一系列動做/消息,好比打電話是從拿起電話撥號到掛斷電話這中間的一系列過程能夠稱之爲一個session。
然而當session一詞與網絡協議相關聯時,它又每每隱含了「面向鏈接」和/或「保持狀態」這樣兩個含義。
session在Web開發環境下的語義又有了新的擴展,它的含義是指一類用來在客戶端與服務器端之間保持狀態的解決方案。有時候Session也用來指這種解決方案的存儲結構。
session機制是一種服務器端的機制,服務器使用一種相似於散列表的結構(也可能就是使用散列表)來保存信息。
但程序須要爲某個客戶端的請求建立一個session的時候,服務器首先檢查這個客戶端的請求裏是否包含了一個session標識-稱爲session id,若是已經包含一個session id則說明之前已經爲此客戶建立過session,服務器就按照session id把這個session檢索出來使用(若是檢索不到,可能會新建一個,這種狀況可能出如今服務端已經刪除了該用戶對應的session對象,但用戶人爲地在請求的URL後面附加上一個JSESSION的參數)。
若是客戶請求不包含session id,則爲此客戶建立一個session而且生成一個與此session相關聯的session id,這個session id將在本次響應中返回給客戶端保存。
A.保存session id的方式能夠採用cookie,這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發送給服務器。
B.因爲cookie能夠被人爲的禁止,必須有其它的機制以便在cookie被禁止時仍然可以把session id傳遞迴服務器,常常採用的一種技術叫作URL重寫,就是把session id附加在URL路徑的後面,附加的方式也有兩種,一種是做爲URL路徑的附加信息,另外一種是做爲查詢字符串附加在URL後面。網絡在整個交互過程當中始終保持狀態,就必須在每一個客戶端可能請求的路徑後面都包含這個session id。
C.另外一種技術叫作表單隱藏字段。就是服務器會自動修改表單,添加一個隱藏字段,以便在表單提交時可以把session id傳遞迴服務器。
一個常見的錯誤是覺得session在有客戶端訪問時就被建立,然而事實是直到某server端程序(如Servlet)調用HttpServletRequest.getSession(true)這樣的語句時纔會被建立。
session在下列狀況下被刪除:
A.程序調用HttpSession.invalidate()
B.距離上一次收到客戶端發送的session id時間間隔超過了session的最大有效時間
C.服務器進程被中止
再次注意關閉瀏覽器只會使存儲在客戶端瀏覽器內存中的session cookie失效,不會使服務器端的session對象失效。
對全部的URL使用URL重寫,包括超連接,form的action,和重定向的URL。每一個引用你的站點的URL,以及那些返回給用戶的URL(即便經過間接手段,好比服務器重定向中的Location字段)都要添加額外的信息。
這意味着在你的站點上不能有任何靜態的HTML頁面(至少靜態頁面中不能有任何連接到站點動態頁面的連接)。所以,每一個頁面都必須使用servlet或JSP動態生成。即便全部的頁面都動態生成,若是用戶離開了會話並經過書籤或連接再次回來,會話的信息都會丟失,由於存儲下來的連接含有錯誤的標識信息-該URL後面的SESSION ID已通過期了。
僅當每一個頁面都是有表單提交而動態生成時,才能使用這種方法。單擊常規的<A HREF..>超文本連接並不產生表單提交,所以隱藏的表單域不能支持一般的會話跟蹤,只能用於一系列特定的操做中,好比在線商店的結帳過程
1.訪問與當前請求相關的會話對象
2.查找與會話相關的信息
3.存儲會話信息
4.廢棄會話數據
getSession()/getSession(true):當session存在時返回該session,不然新建一個session並返回該對象
getSession(false):當session存在時返回該session,不然不會新建session,返回null
setAttribute會替換任何以前設定的值;若是想要在不提供任何代替的狀況下移除某個值,則應使用removeAttribute。這個方法會觸發全部實現了HttpSessionBindingListener接口的值的valueUnbound
方法。
一般會話屬性的類型只要是Object就能夠了。除了null或基本類型,如int,double,boolean。
若是要使用基本類型的值做爲屬性,必須將其轉換爲相應的封裝類對象
A.只移除本身編寫的servlet建立的數據:
調用removeAttribute(「key」)將指定鍵關聯的值廢棄
B.刪除整個會話(在當前Web應用中):
調用invalidate,將整個會話廢棄掉。這樣作會丟失該用戶的全部會話數據,而非僅僅由咱們
servlet或JSP頁面建立的會話數據
C.將用戶從系統中註銷並刪除全部屬於他(或她)的會話
調用logOut,將客戶從Web服務器中註銷,同時廢棄全部與該用戶相關聯的會話(每一個Web應用至多一個)。這個操做有可能影響到服務器上多個不一樣的Web應用
public boolean isNew()方法若是會話還沒有和客戶程序(瀏覽器)發生任何聯繫,則這個方法返回true,這通常是由於會話是新建的,不是由輸入的客戶請求所引發的。
但若是isNew返回false,只不過是說明他以前曾經訪問該Web應用,並不表明他們曾訪問過咱們的servlet或JSP頁面。
由於session是與用戶相關的,在用戶以前訪問的每個頁面都有可能建立了會話。所以isNew爲false只能說用戶以前訪問過該Web應用,session能夠是當前頁面建立,也多是由用戶以前訪問過的頁面建立的。
正確的作法是判斷某個session中是否存在某個特定的key且其value是否正確
會話的超時由服務器來維護,它不一樣於Cookie的失效日期。首先,會話通常基於駐留內存的cookie
不是持續性的cookie,於是也就沒有截至日期。即便截取到JSESSIONID cookie,併爲它設定一個失效日期發送出去。瀏覽器會話和服務器會話也會大相徑庭。
當用戶關閉了瀏覽器雖然session cookie已經消失,但session對象仍然保存在服務器端
程序通常都是在用戶作log off的時候發個指令去刪除session,然而瀏覽器歷來不會主動在關閉以前通知服務器它將要被關閉,所以服務器根本不會有機會知道瀏覽器已經關閉。服務器會一直保留這個會話對象直到它處於非活動狀態超過設定的間隔爲止。
之因此會有這種錯誤的認識,是由於大部分session機制都使用會話cookie來保存session id,而關閉瀏覽器後這個session id就消失了,再次鏈接到服務器時也就沒法找到原來的session。
若是服務器設置的cookie被保存到硬盤上,或者使用某種手段改寫瀏覽器發出的HTTP請求報頭,把原來的session id發送到服務器,則再次打開瀏覽器仍然可以找到原來的session。
偏偏是因爲關閉瀏覽器不會致使session被刪除,迫使服務器爲session設置了一個失效時間,當距離客戶上一次使用session的時間超過了這個失效時間時,服務器就能夠認爲客戶端已經中止了活動,纔會把session刪除以節省存儲空間。
由此咱們能夠得出以下結論:
關閉瀏覽器,只會是瀏覽器端內存裏的session cookie消失,但不會使保存在服務器端的session對象消失,一樣也不會使已經保存到硬盤上的持久化cookie消失。
一般session cookie是不能跨窗口使用的,當你新開了一個瀏覽器窗口進入相同頁面時,系統會賦予你一個新的session id,這樣咱們信息共享的目的就達不到了。
此時咱們能夠先把session id保存在persistent cookie中(經過設置session的最大有效時間),而後在新窗口中讀出來,就能夠獲得上一個窗口的session id了,這樣經過session cookie和persistent cookie的結合咱們就能夠實現了跨窗口的會話跟蹤。
因爲客戶的訪問次數是一個整型的變量,但session的屬性類型中不能使用int,double,boolean等基本類型的變量,因此咱們要用到這些基本類型的封裝類型對象做爲session對象中屬性的值
但像Integer是一種不可修改(Immutable)的數據結構:構建後就不能更改。這意味着每一個請求都必須建立新的Integer對象,以後使用setAttribute來代替以前存在的老的屬性的值。例如:
HttpSession session = request.getSession(); SomeImmutalbeClass value = (SomeImmutableClass)session.getAttribute(「SomeIdentifier」); if (value= =null){ value = new SomeImmutableClass(…); // 新建立一個不可更改對象 }else{ value = new SomeImmutableClass(calculatedFrom(value)); // 對value從新計算後建立新的對象 } session.setAttribute(「someIdentifier」,value); // 使用新建立的對象覆蓋原來的老的對象
使用可變的數據結構,好比數組、List、Map或含有可寫字段的應用程序專有的數據結構。經過這種方式,除非首次分配對象,不然不須要調用setAttribute。例如
HttpSession session = request.getSession(); SomeMutableClass value = (SomeMutableClass)session.getAttribute(「someIdentifier」); if(value = = null){ value = new SomeMutableClass(…); session.setAttribute(「someIdentifier」,value); }else{ value.updateInternalAttribute(…); // 若是已經存在該對象則更新其屬性而不需從新設置屬性 }
不可更改對象由於一旦建立以後就不能更改,因此每次要修改會話中屬性的值的時候,都須要
調用setAttribute(「someIdentifier」,newValue)來代替原有的屬性的值,不然屬性的值不會被更新
可更改對象由於其自身通常提供了修改自身屬性的方法,因此每次要修改會話中屬性的值的時
候,只要調用該可更改對象的相關修改自身屬性的方法就能夠了。這意味着咱們就不須要調
用setAttribute方法了
考官說要不先作一下自我介紹吧,因爲緊張而後把學校裏自我簡紹的磨練給忘了只是簡短的作了姓名年齡畢業學校的回答,徹底忘了把特長興趣愛好介紹了,回來後才發現本身腦子當時幹嗎了第二,考官問你對公司瞭解多少呢,必定要記得面試前下點功夫,而後若是實在不知道就實事求是就能夠,考官通常都挺好的,他在你不知道狀況下會簡短的把公司概況說一下的,而後回問你對本身專業以及將來發現方向,三到五年的規劃什麼的,必定要面試前把規劃計劃好再就是你的簡歷問題,必定要實事求是,他們會從你簡歷裏挑你很擅長的東西查看你的掌握狀況以及真實度從而側面看你人品還提了不少專業知識的問題最後會問你對薪資,以及本身對公司有什麼要求呀,你還有什麼問題呀之類,但問的必定不要問太多,一個兩個表明性的就夠了。