jsp停車場(chǎng)收費(fèi)系統(tǒng)ssh論文

根據(jù)前幾個(gè)階段的分析和設(shè)計(jì)，本系統(tǒng)在設(shè)計(jì)方面采用B/S模式，同時(shí)使用JSP技術(shù)進(jìn)行基本頁面的設(shè)計(jì)與功能實(shí)現(xiàn)，后臺(tái)數(shù)據(jù)庫選用MySQL數(shù)據(jù)庫。本系統(tǒng)的設(shè)計(jì)實(shí)施為停車場(chǎng)收費(fèi)系統(tǒng)的運(yùn)行做基礎(chǔ)，為停車場(chǎng)收費(fèi)系統(tǒng)提供良好的條件。從停車場(chǎng)收費(fèi)系統(tǒng)角度出發(fā)，整體分析和構(gòu)建數(shù)據(jù)庫應(yīng)用系統(tǒng)，充分利用JSP開發(fā)環(huán)境提供的開發(fā)技術(shù)，實(shí)現(xiàn)停車場(chǎng)完善的收費(fèi)體系。2)采用軟件工程的方法完成本設(shè)計(jì)，提高軟件開發(fā)綜合能力，了解軟件系統(tǒng)架構(gòu)設(shè)計(jì)能力和軟件過程實(shí)施能力，從而培養(yǎng)軟件工程的整體使用能力。管理員編號(hào)（主鍵）用戶名用戶密碼車型編號(hào)（主鍵）車型名稱字段名數(shù)據(jù)類型長(zhǎng)度功能描述車位編號(hào)（主鍵）車位狀態(tài)字段名數(shù)據(jù)類型長(zhǎng)度功能描述idInt4編號(hào)（主鍵）Chexingvarchar20車型Startdatetime8開始時(shí)間Enddatetime8結(jié)束時(shí)間Price字段名數(shù)據(jù)類型長(zhǎng)度功能描述idInt4編號(hào)（主鍵）balanceint20typevarchar8類型timedatetime8辦理時(shí)間內(nèi)存是所有程序都需要的一種資源，然而明智的內(nèi)存用法正在變成丟失的藝術(shù)。為Microsoft?.NETFramework編寫的托管應(yīng)用程序依靠垃圾回收器來分配和清理內(nèi)存。對(duì)于很多應(yīng)用程序而言，花費(fèi)3%到5%的CPU時(shí)間來執(zhí)行垃圾回收(GC)是一個(gè)公平的折衷方案，這樣就無須擔(dān)心內(nèi)存管理問題。但是，對(duì)于CPU時(shí)間和內(nèi)存都是寶貴資源的應(yīng)用程序而言，盡量減少花費(fèi)在垃圾回收方面的時(shí)間可以大大提高應(yīng)用程序的性能和健壯性。如果應(yīng)用程序可以更有效地使用可用內(nèi)存，則垃圾回收器的運(yùn)行頻率就會(huì)降低，并且運(yùn)行的時(shí)間也會(huì)縮短。因此，請(qǐng)不要在應(yīng)用程序中考慮垃圾回收器做什么或者不做什么，而要直接考慮內(nèi)存用法。大多數(shù)生產(chǎn)計(jì)算機(jī)都具有數(shù)量巨大的RAM，并且從全局來看，諸如使用短整數(shù)而不是常規(guī)整數(shù)之類的優(yōu)化可能似乎沒有多大意義。在本文中，我將改變您的看法。我將考察類型大小調(diào)整、各種設(shè)計(jì)技術(shù)以及如何分析程序的內(nèi)存利用。我的示例將重點(diǎn)討論C#，但是該討論同樣適用于VisualBasic?.NET、托管C++以及您能夠想到的其他任何面向.NET的語言。我假設(shè)您了解有關(guān)垃圾回收工作方式的基礎(chǔ)知識(shí)，包括相關(guān)的概念，如生成、處置模式和弱引用。如果您不熟悉這些概念，則請(qǐng)參閱JeffreyRichter撰寫的有關(guān)垃圾回收的出色文章：GarbageCollection:AutomaticMemoryManagementintheMicrosoft.NETFramework。內(nèi)存用法最終取決于程序中的程序集所定義和使用的類型，因此讓我們首先分析一下系統(tǒng)中各種類型的大小。圖1顯示了System命名空間中定義的核心.NET值類型的大?。ㄗ止?jié)），以及它們等效的C#類型。我使用不安全的代碼和C#sizeof運(yùn)算符來驗(yàn)證這些值類型在托管內(nèi)存中的大小。對(duì)于其中一些類型（包括bool和char），使用Marshal.SizeOf方法而不是sizeof運(yùn)算符會(huì)產(chǎn)生不同的值，這是由于Marshal.SizeOf計(jì)算封送處理類型的非托管大小，并且這些類型不是直接復(fù)制到本機(jī)結(jié)構(gòu)中的（這意味著它們?cè)谕泄艽a和非托管代碼之間傳遞時(shí)，可能需要轉(zhuǎn)換）。稍后將對(duì)此進(jìn)行詳細(xì)討論。結(jié)構(gòu)（值類型）的大小被計(jì)算為其字段大小的總和，外加由于將這些字段與其自然邊界對(duì)齊而增加的任何開銷。引用類型的大小是其字段大小向上舍入到下一個(gè)4字節(jié)邊界，外加8字節(jié)的開銷。（要了解您的引用類型使用多少空間，您可以度量堆大小在分配它們時(shí)的變化，或者可以使用稍后討論的CLR分析器工具。）這意味著所有引用類型都至少占用12字節(jié)，因此在C#中，長(zhǎng)度小于16字節(jié)的任何對(duì)象作為結(jié)構(gòu)可能更有效一些。當(dāng)然，如果您需要存儲(chǔ)類型的引用，則結(jié)構(gòu)會(huì)有問題，因?yàn)轭l繁的裝箱可能耗盡內(nèi)存和CPU周期。因而，謹(jǐn)慎地使用結(jié)構(gòu)是很重要的。由于字段對(duì)齊可能影響類型的大小，因此類型內(nèi)部的字段組織在其最終大小方面扮演重要的角色。類型的布局以及具有該布局的字段的組織受到應(yīng)用于類型的StructLayoutAttribute的影響。默認(rèn)情況下，C#、VisualBasic.NET和C++編譯器都將StructLayoutAttribute應(yīng)用于結(jié)構(gòu)，以指定Sequential布局。這意味著字段按照它們?cè)谠次募械捻樞虿贾迷陬愋椭?。但是，?NETFramework1.x中，對(duì)Sequential布局的請(qǐng)求不會(huì)被即時(shí)編譯器(JIT)遵守，即使該請(qǐng)求是由封送拆收器提出的。在.NETFramework2.0中，JIT確實(shí)為值類型的托管布局實(shí)施了Sequential布局（如果指定的話），盡管前提是沒有引用類型字段成員。因而，在下一個(gè)版本的Framework中，類型的大小調(diào)整可能會(huì)更加重要。在所有版本中，對(duì)Explicit布局（其中，由開發(fā)人員指定每個(gè)字段的字段偏移量）的請(qǐng)求同時(shí)被JIT和封送拆收器遵守。我之所以進(jìn)行這一區(qū)分，是因?yàn)轭愋偷姆馑筒季滞ǔＥc該類型的堆?；騁C堆布局不同。封送類型的布局必須