接口(Interface)和抽象类(abstract,汤姆cat 运维出现音信如下

Java中接口和抽象类的比較-20一三年四月写的读书笔记摘要

汤姆cat 运营出现音讯如下:

1. 概述

       
接口(Interface)和抽象类(abstract
class)是
Java 语言中扶助抽象类的三种机制。是Java程序布置使用多态性的功底[[1]-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_edn1)]。(在面向对象语言中,接口的二种不一致的实现格局即为多态。多态性是同意你将父对象设置成为和3个或诸多别的的她的子对象的技能,赋值之后,父对象就可见根据当前赋值给它的子对象的特点以不相同的主意运转(摘自“Delphi4编制程序技能内幕”)。简单来讲,正是一句话:同意将子类类型的指针赋值给父类类型的指针[[2]-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_edn2)])。

在那么些面向对象(object)的次第设计语言的概念中。类(classss)指的是一种浮泛的数据类型、是创设对象在脑子中的主观反映、是目的共性的虚幻、类型同样事物数据的抽象。能够说。全部的对象都无法不通过类来开始展览勾勒叙述,但是全部的类却不自然都是用来对目的来拓展摹写叙述的。

借使某二个类中所包罗的音信不足以用来描写叙述三个详尽的靶子,那么大家就称其为抽象类(abstract class)。抽象类是我们在对某一主题素材领域拓展规划和剖析时所得出的抽象概念,是壹体系本质上同1,而外在形象各异的详细概念的架空反映[[3]-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_edn3)]。比方:假诺大家进行2个图形编辑软件的开荒,就会发觉标题领域存在着圆、三角形那样局地详尽概念,它们是例外的,但是它们又都属于形状那样二个定义。形状这一个定义在主题材料领域是不设有的,它正是多个抽象概念。便是由于抽象的定义在难题领域尚未相应的详尽概念,所以用以代表抽象概念的抽象类是无法实例化对象的。

接口好比是先后之间的3个约定或合同,但它仅仅定义了行为的协商。并未有定义执行接口协议的详尽措施。接口中单单内定抽象方法的方法头。但不提供抽象方法的事无巨细落成。接口定义的单独是贯彻某种特定功用的1组对外接口和正式,而其详细效能的兑现是在落到实处那一个接口的种种类中甘休的[1],二个类达成了有个别接口,我们就说这几个类符合了有些约定。

接口表示①种能力[4],3个类完结了有个别接口,就表示这一个类具备了某种本事。

生存中1个人能够具有多项工夫。3个类也能够落到实处多少个接口。

抽象类重申的是“概念”,接口强调的是“才干”(只怕说是“行为”)。

2.Java中的接口和抽象类的相似之处

(一)抽象类和接口都能促成对一组行为的悬空,接口和抽象类都可回顾抽象方法。

承继(完结)它们的类实例必须具有落成它们定义的聊以自慰方法后本事用于实例化对象(只是,抽象类能够三个空洞方法都未曾);

(二)接口和抽象类木身都无法用于对象实例化,但它们的引用能够针对承接(达成)它们的类实例从而动态地接纳那一个类实例。

信息: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:XXXX

三. Java中的接口和抽象类的差异

1) 属性:抽象类中能够有变量,而接口中无法定义变量,即接口中属性都会自个儿主动用public
static final来修饰,都以全局静态常量,且必须在概念时钦命开端值。

2) 方法:抽象类中能够有详细措施和虚幻方法,抽象类的子类也能够是抽象类;而接口中全体形式都以空泛方法,接口中方法都会协调主动用public
abstract修饰。因为接口不关乎达成。从这点上看,接口在抽象化程度方面比抽象类的更加高。

3) 继承性:抽象类属于1种独特的类。类的接续必须满意三个子类仅仅能有多少个父类(单继承),但亦可得以落成多少个接口(多达成)。

而接口能够达成多连续。即一个接口能够有三个父接口。

4) 设计观念[1]:
那或多或少也是最实质的有个别。对于抽象类与接口的选项拾1分主要。对于抽象类来说。抽象类与其子类之间存在多个“is
a”的存在延续关系,即双方产生层次结构,父类和子类在概念本质上是平等的。

图片 1

如Shape类与其子类Circle , Square
,Triangle在真相上是均等的,显著存在3个“is
a”关系。即Circle(圆形)、Square(矩形),Triangle(三角形)都属于Shape形状。

对于接口来讲.接口与贯彻它的类之间不设有仟何层次关系。

也不须求接口和达成它的类之间在概念本质上平等。仅仅须求接口的达成者实现接口规定的成效。接口能够完成毫无干系类的同样作为。比抽象类的运用越来越有益于灵活。比方定义三个接口open_close表示按钮行为:

interface  open_close{

void
open();

void
close();

}

门door有按钮成效,能够让Door类完成open_close接口。

class Door implements open_close
{

void
open() {……}

 
void close() {……}

 }

手提式有线话机MobileTelephone有按键功效。能够让mobileTelephone类达成open_close接口。

class MobileTelephone implements
open_close {

void
open() {……}

void
close() {……}

 }

计算机computer有开关作用。能够让Computer类达成open_close接口。

   class Computer implements open_close
{

void
open() {……}

void
close() {……}

 }

从该例可以看到,类Door,
MobileTelephone,Computer与接口open_close之间不设有不论什么层次关系。它们中间是“has”关系,即Door,
MobileTelephone,计算机都独具接口open_close钦点的效果。

透过接口open_close落成了毫无干系类Door,
MobileTelephone,Computer的一道行为。再举个不太可信,但是好通晓的样例,在学堂的学生音信管理软件中“笔者是1个能打篮球、踢足球的学员”能够定义为:

class Me extends
Student implementsIPlayBasketeball, IPlayFootball { }

作者是学生,由此作者extends
Student,作者有打篮球,踢足球的力量,因而小编完成IPlayBasketeball,
IPlayFootball,笔者就具备了IPlayBasketeball,
IPlayFootball接口提供的各类表现(如,传球,头球,射门等),而且本身要好落成它们。

四.接口与抽象类的取舍[4]-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_edn4)

缅想这么2个样例,尽管我们在为八个电器生产商家开采手提式无线电话机软件,难点领域中有2个有关手提式有线电话机的抽象概念,该手机械和工具1些动作如开机。关机等,此时大家能够透过接口只怕抽象类来定义一个象征该抽象概念的项目。定义方式分别例如以下所观望的:

利用接口格局定义手提式有线电话机:

interface Mobile_phone{

void
open();

void
close();

}

采纳抽象类情势定义手提式有线电话机:

abstract class Mobile_phone{

abstract void open();

abstract void close();

}

而详尽的无绳话机项目(如A18型,B30型)可以承继抽象类格局定义,或然选择完毕接口的主意定义。看起来好像使用接口和抽象类未有大的反差。

但随着才能的提升,要是近来需求手提式有线电话机要合并有信用卡的功力。

大家应当怎么设计针对性该样例的类协会吧?信用卡的1对基木效能有,电子卡包,消费等,这一个功能和手提式有线电话机的开机关机功用属于多少个不等的定义,依据接口隔开原则(ISP。Interface
Segregation
Principle)应该把它们各自定义在表示那三个概念的悬空意味(接口也许抽象类)中。那时“信用卡”那一个抽象概念的定义恐怕是那三种状态:

interface Creditcard {

void
e_wallet();

void
consume();

}

abstract class Creditcard {

abstract void a_ wallet();

abstract void consume();

}

那时手提式有线电话机和银行卡那八个概念的概念格局就有了三种也许的咬合,例如以下表:

 

手机

信用卡

方案A

定义为抽象类

定义为抽象类

方案B

定义为抽象类

定义为接口

方案C

定义为接口

定义为抽象类

方案D

定义为接口

定义为接口

方案A(几个概念都定义为抽象类)能够及时解除。由于Java不帮衬多一连,完毕类那无法等同时候承接这一个抽象类。在那边能够见到抽象类在经过概念的结缘来扩张功效的时候是

不便宜的。

别的的不2秘籍当下从语法上都以实用的,但何人更合理是值得考究的。

先研商一下方案C(“手提式有线电话机”定义为接口;“信用卡”定义为抽象类),那时完毕这五个概念的类和那多少个概念之间的涉及就是。“like”手提式有线电话机,“is”信用卡。也正是说实现手提式有线电话机接口、承接信用卡抽象类的子类具有手提式无线电电话机的功用。可是本质上是信用卡。

强烈那和我们对标题领域的接头不符。由于带信用卡功用的“手提式有线电话机”在概念本质上是手提式有线电话机,同一时半刻候拥有信用卡的功效能够像信用卡一样选取)。

就此那几个艺术是不创设的。除非我们是在为信用卡的创造商写软件,他们期望扩大手提式有线电话机的功用。

与此同时。借使手提式有线电电话机再扩大成效,如电子地图,导航器等等,把这么的扩大的作用概念像信用卡”同样定义为抽象类的话,由于Java的单继承机制,那是无法达成的。

那道理和方案A同样,把用来扩张功效的定义定义为抽象类并不得体。

方案B(“手机”定义为抽象类;“信用卡”定义为接口)应该是目前最合情合理的规划了。那时反映出的定义是is手机,like“信用卡”。

借使有扩张功效的话,能够再定义成接口,成为“is手机,like信用卡like电子地图”。从而科学的感应大家面对的难点域。  

那方案D两者都定义为接口。是否就十二分吗?

争论方案C来讲,方案D的筹划未有显示入手提式有线电电话机”是主题素材领域的真相的关键性,使人有究竟我们在搞手提式无线电话机也许信用卡依旧其他什么事物?

”那些疑问。那么些毛病是不容置疑的。但从还有多只来讲:“手提式有线话机”这几个定义定义成接口,在软件规模扩展的前提下,可能为之后别的的组件的利用提供了便利。

比方说,如果厂商又有二个遥控器”的概念要我们陈设,要把手提式有线电话机的功效设计进去,那时时候手提式有线话机”假若是接口就方便了,implements他就可以。所以说,方案D是捐躯了定义的清晰性,获得了扩展

只要预感觉难题领域以往从未太大转移,方案B是最棒的。方案D在方今是不适用的,但在之后的恢宏中大概非凡有利于。此间收获的下结论就是:借使仅仅是在概念一组行为框架的话,抽象类合适用来定义难题领域中的本质的抽象概念,接口合适用来定义扩张功用的抽象概念。  

 

 
在刚刚那一个样例中“手提式有线电话机”,“信用卡”可是壹组抽象方法,也便是概念中富含的但是作为框架未有达成,这时候定义成抽象类或接口都有协调的道理。设若概念中己经含有了贯彻。那时候就把该概念定义成抽象类了。

 
比方2个“A种类打印机”的抽象类,由他定义区别品类的打字与印刷机,那一文山会海的打字与印刷机打字与印刷页头,页脚的方案都以相同的,但打字与印刷页面主体比較复杂。各类详细型号的打印机的各有它们不一样的打字与印刷格局。那时能够如此设计:   

方案一:根据打字与印刷机应该打字与印刷完整页面包车型大巴自然逻辑,
PrintBody()抽象方法是打字与印刷机那几个概念的1局部。设计为抽象类:

abstract class A_SeriesPrinter{

abstract protected void
PrintBody();

public void OutReport() {

PrintHeader();

PrintBody();

PrintFooter();

}

protected void Draw(String str) {
 /\
完成的代码*/ }*

protected void PrintHeader() {        
Draw(“Head”);/\
贯彻的代码*/      }*

protected void PrintFooter() {          
Draw(“Footer”);/\
落到实处的代码*/   }*

}

}

一连抽象类的代码:

classXXPrinter extends A_ SeriesPrinter
{

protected void PrintBody() {   
/\
兑现的代码‘/ }*

}

classYYPrinter extends A_SeriesPrinter 
{

protected void PrintBody() {   
/\
落到实处的代码‘/ }*

}

选取的代码:

XXPrinter xx = new XXPrinter();

xx.OutReport();

YYPrinter yy = new YYPrinter();

yy.OutReport();

旗帜分明那么些法子是粗略而知晓的。

方案二:为了扩大性。硬把PrintBody()抽象方法抽取来改成贰个接口IBody,代码例如以下:

abstractclass A_SeriesPrinter { 
//思虑一下,还用abstract么?

protected void Draw( String str) {   
/\
兑现的代码*/      }*

protected void PrintHeader() {  
Draw(“Head”);/\
贯彻的代码*/        }*

protected void PrintFooter() {       
Draw(“Footer”);/\
得以完毕的代码*/ }*

}

interface IBody{

void
PrintBody();//多了3个IBody接口的概念

}

在此处先解决二个标题,借使Printer去掉了PrintBody()抽象方法。都以兑现了的主意,是否就相应把它定义为壹般的类呢?

答案是或不是定的,设计3个抽象概念为抽象类的意思,不是由于它涵盖抽象方法。而关键是因为是他意味着的概念不该被实例化,尽管它在那之中的点子全体是贯彻了的,仅仅是想让子类承接的代码。在地点那一个样例中,“A类别打字与印刷机”那一个概念,是不应当有实例的,有实例的相应是事无巨细型号的打字与印刷机。

就此,即就是颇具是促成了的方法。方案贰中的A_SeriesPrinter依旧定义成抽象类越来越好。  

一而再看承接类并促成接口的代码:

classXXPrinter extends 
A_SeriesPrinterimplements IBody {

public void PrintBody()    {      
;/\
兑现的代码*/     }*

public void OutReport() {  //
OutReport()被迫移到了落到实处类

PrintHeader();

PrintBody();

PrintFooter(); 

}

}

classYYPrinter extends 
A_SeriesPrinterimplements Body {

public void PrintBody() {
;/\
完成的代码*/}*

public void OutReport(){  //
OutReportQ被迫移到了达成类

PrintHeader();

PrintBody();

PrintFooter();

}

}

行使的代码:

XXPrinter xx = new XXPrinterQ;

xxDutReportQ;

YYPrinter yy = new YYPrinterQ;

yy.OutReportQ;  

这么做会议及展览示相当想获得和复杂性: class XXPrinter extends Printer
implementsIBody?好像打字与印刷Body居然是打字与印刷机的附加成效?

(那太令人难以知晓了),还无端的多出了叁个IBody接口的定义。并且,OutReport()被迫移到了一一落成类。代码变长并且复杂了。所以那时抽象类是最棒的挑3拣四。除非有事情需求必须把Body的打字与印刷从打印机分离出来。套到别的概念中去。这时才有思虑使它造成接口的可能,但再次提示大家。代码会变得复杂。

顺藤摸瓜难题出现的源流。是出于PrintBody()那一个抽象方法和打印机那个定义结合的太紧凑了,它自己就是打字与印刷机功能的必需的一部分。贪图接口语法上的灵活性,自目的言情扩充性开放性,而不顾对难题领域的精晓而建立模型,仅仅要某三个定义(A_SeriesPrinter)中富含的表现框架(PrintBody())都分离出来搞成接口,就会有一文山会海的编码上和明白上的劳动。反而增加了代码的复杂性。

不过,就算在动用抽象类的场面。也不要忽略通过接口定义行为模型的基准。假若重视于抽象类来定义行为。往往产生过度复杂的延续关系。而透过接口定义行为能够更有效地分手行为与落成,为代码的保卫安全定祥和更动带来有利。比方小编扩充A_
SeriesPrinter类。在打字与印刷后加个日志消息。如viod outLog()方法,那么笔者就不应当把它定义成A_SeriesPrinter类的指雁为羹方法了。而是日志接口的空洞方法。

出于“日志”那概念不属于打字与印刷机的专有范畴。

这样未来其余模块用到关于日志的操作规范时得以便宜地用到这么些日志接口。

从而。关键在于是不是能完美地组合事业供给对难点域进行驾驭分析。即使你从未办好那一点,你就无法树立合理的模子,那时要不正是增添编码的错综复杂,可精通性,要不正是代码难以随着业务扩展而敬爱和更改。

 

综上,

1) 假定仅仅是在概念一组行为框架的话(抽象类和接口都能够达成),抽象类合适用来定义

标题领域中的本质的抽象概念。接口合适用来定义扩充作用的抽象概念。

2) 当要求为局地有关的类提供公共的兑今世码时,应该先行考虑用抽象类来促成,由于抽

象类中的非抽象方法能够被子类承袭下来,使贯彻效益的代码更简明

3) 当另眼相看代码的扩充型和可维护性时,应该事先考虑采纳接口,原因有:一接口与贯彻它

的类之间能够不存在不论什么层次关系,接口能够落到实处无关类的1模同样作为,比抽象类的利用进一步有利灵活;2接口只是关心对象之间的竞相的措施,而不关切对象所对应的详细类。接口是先后之间的三个共谋。比抽象类的运用更安全、清晰。一般选拔接口的情景多多任何[1]。

轻便易行说的说“在单独是概念1组行为框架时。对于与难题域中的抽象概念的定义应该事先思量採用抽象类。要为一些相关类提供公共的达成代码时。应该先行考虑採用抽象类。别的情状都应当事先思量採用接口”。

——zhouyong 

补充:

问题域[[5]-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_edn5)](Problemdomain):指提问的界定、难点之间的内在的关系和逻辑可能性空间。

在软件project中,难点域是指被支付类别的应用领域,即在创立世界中由该种类处理的业务范围。

 


-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_ednref1)[[1]]阳小兰
钱程 赵海廷. Java中抽象类和接口的行使研商.Software Guide, Vo一.玖 No.10Oct.20拾

-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_ednref2)[[2]]百度周密:http://baike.baidu.com/view/126521.htm

-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_ednref3)[[3]]颜瑞江.
Java中抽象类和接口的分歧与联系.

-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_ednref4)[[4]]刘虢俊.
浅析Java的接口和浮泛类.
Computer与音信才具,200七年7月,第三1期总第柒八期)

-From%E5%91%A8%E6%B6%8C-2013%E5%B9%B45%E6%9C%883%E6%97%A5/2.%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%B8%8E%E6%8E%A5%E5%8F%A3%E7%9A%84%E6%AF%94%E8%BE%83.docx#_ednref5)[[5]]http://baike.baidu.com/view/1128785.htm

 

出现原因剖析:

汤姆cat提出选用apache的apr,来越来越好的运行汤姆cat;

 

———————————————-apache的apr 的介绍

AP奥迪Q5(Apache portable Run-time
libraries,Apache可移植运转库)的目的如其名目1致,首要为上层的应用程序提供1个足以超过多操作系统平台接纳的最底层帮忙接口库。在最初
的Apache版本中,应用程序本身必须能够处理各样实操系统平台的细节,并对准不一致的平台调用不相同的处理函数。

乘机Apache的进一步开垦,Apache协会决定将那个通用的函数独立出来并向上成为三个新的档次。那样,AP猎豹CS6的开荒就从Apache中独立出来,Apache仅仅是应用
APKoleos而已。

APRAV4使得平台细节的处理进展下移。对于应用程序来说,它们根本就不需求考虑实际的平台,不管是Unix、Linux还是Window,应用程序试行的接口基本都以统一壹致的。因而对此APBMWX5来讲,可移植性和集合的上层接口是其思考的3个关键。而APPRADO最早的目的并不是这么,它最早只是梦想将Apache中用到的全数代码合并为1个通用的代码库,可是那不是二个不易的布署,由此后来APRubicon改换了其目的。有的时候使用集体代码并不是一件好事,比如怎么着将3个请求映射到线程大概经过是阳台相关的,由此唯有五个集体的代码库并不可能产生那种分化。APLX570的靶子则是梦想平安合并全体的能够联合的代码而不供给牺牲质量。

AP卡宴的最早的2个对象便是为具备的平台(不是局地)提供多个公共的联合操作函数接口,那是1个至极巨大的目标,当然也是不具体的3个对象。大家不容许帮衬全部平台的保有特征,因而APBMWX伍近期只可以为超越二分一阳台提供全体的APRubicon个性援救,包含Win3二、OS/贰、BeOS、达尔文、Linux等等。为了能够落到实处这几个目的,AP奥迪Q3开垦者必须为那叁个不可能运维于具有平台的性子成立了一文山会海的特征宏(FEATURE
MACROS)以在1一平纽伦堡间差异这一个特点。那些特点宏定义分外简单,常常用APBMWX伍_HAS_FEATURE参数设置:

比方有些平台具备那性情格,则该宏必须设置为true,比如Linux和window都持有内部存款和储蓄器映射文件,同时AP陆风X捌提供了内部存储器映射文件的操作接口,因而在那多个平台上,AP奥迪Q5_HAS_MMAP宏必须设置,同时ap_mmap_*函数应该将磁盘文件映射为内部存款和储蓄器并回到适当的状态码。假使您的操作系统并不帮忙内部存款和储蓄器映射,那么AP本田CR-V_HAS_MMAP必须安装为0,而且具有的ap_mmap_*函数也能够不需求定义。第一步便是对于那八个在程序中选择了不协助的函数必须建议警告。

 

消除措施:

下载与你汤姆cat对应版本的 tcnative-1.dll,放到apache-tomcat-7.0.57\bin
目录下,重启tomcat。

下载地址:http://archive.apache.org/dist/tomcat/tomcat-connectors/native/%E7%9A%84%E7%9B%AE%E7%9A%84%E5%A6%82%E5%85%B6%E5%90%8D%E7%A7%B0%E4%B8%80%E6%A0%B7%EF%BC%8C%E4%B8%BB%E8%A6%81%E4%B8%BA%E4%B8%8A%E5%B1%82%E7%9A%84%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E6%8F%90%E4%BE%9B%E4%B8%80%E4%B8%AA%E5%8F%AF%E4%BB%A5%E8%B7%A8%E8%B6%8A%E5%A4%9A%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E5%B9%B3%E5%8F%B0%E4%BD%BF%E7%94%A8%E7%9A%84%E5%BA%95%E5%B1%82%E6%94%AF%E6%8C%81%E6%8E%A5%E5%8F%A3%E5%BA%93%E3%80%82%E5%9C%A8%E6%97%A9%E6%9C%9F%20%E7%9A%84Apache%E7%89%88%E6%9C%AC%E4%B8%AD%EF%BC%8C%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E6%9C%AC%E8%BA%AB%E5%BF%85%E9%A1%BB%E8%83%BD%E5%A4%9F%E5%A4%84%E7%90%86%E5%90%84%E7%A7%8D%E5%85%B7%E4%BD%93%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E5%B9%B3%E5%8F%B0%E7%9A%84%E7%BB%86%E8%8A%82%EF%BC%8C%E5%B9%B6%E9%92%88%E5%AF%B9%E4%B8%8D%E5%90%8C%E7%9A%84%E5%B9%B3%E5%8F%B0%E8%B0%83%E7%94%A8%E4%B8%8D%E5%90%8C%E7%9A%84%E5%A4%84%E7%90%86%E5%87%BD%E6%95%B0%E3%80%82%20%20%E9%9A%8F%E7%9D%80Apache%E7%9A%84%E8%BF%9B%E4%B8%80%E6%AD%A5%E5%BC%80%E5%8F%91%EF%BC%8CApache%E7%BB%84%E7%BB%87%E5%86%B3%E5%AE%9A%E5%B0%86%E8%BF%99%E4%BA%9B%E9%80%9A%E7%94%A8%E7%9A%84%E5%87%BD%E6%95%B0%E7%8B%AC%E7%AB%8B%E5%87%BA%E6%9D%A5%E5%B9%B6%E5%8F%91%E5%B1%95%E6%88%90%E4%B8%BA%E4%B8%80%E4%B8%AA%E6%96%B0%E7%9A%84%E9%A1%B9%E7%9B%AE%E3%80%82%E8%BF%99%E6%A0%B7%EF%BC%8CAPR%E7%9A%84%E5%BC%80%E5%8F%91%E5%B0%B1%E4%BB%8EApache%E4%B8%AD%E7%8B%AC%E7%AB%8B%E5%87%BA%E6%9D%A5%EF%BC%8CApache%E4%BB%85%E4%BB%85%E6%98%AF%E4%BD%BF%E7%94%A8%20APR%E8%80%8C%E5%B7%B2%E3%80%82%20%20APR%E4%BD%BF%E5%BE%97%E5%B9%B3%E5%8F%B0%E7%BB%86%E8%8A%82%E7%9A%84%E5%A4%84%E7%90%86%E8%BF%9B%E8%A1%8C%E4%B8%8B%E7%A7%BB%E3%80%82%E5%AF%B9%E4%BA%8E%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E8%80%8C%E8%A8%80%EF%BC%8C%E5%AE%83%E4%BB%AC%E6%A0%B9%E6%9C%AC%E5%B0%B1%E4%B8%8D%E9%9C%80%E8%A6%81%E8%80%83%E8%99%91%E5%85%B7%E4%BD%93%E7%9A%84%E5%B9%B3%E5%8F%B0%EF%BC%8C%E4%B8%8D%E7%AE%A1%E6%98%AFUnix%E3%80%81Linux%E8%BF%98%E6%98%AFWindow%EF%BC%8C%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E6%89%A7%E8%A1%8C%E7%9A%84%E6%8E%A5%E5%8F%A3%E5%9F%BA%E6%9C%AC%E9%83%BD%E6%98%AF%E7%BB%9F%E4%B8%80%E4%B8%80%E8%87%B4%E7%9A%84%E3%80%82%E5%9B%A0%E6%AD%A4%E5%AF%B9%E4%BA%8EAPR%E8%80%8C%E8%A8%80%EF%BC%8C%E5%8F%AF%E7%A7%BB%E6%A4%8D%E6%80%A7%E5%92%8C%E7%BB%9F%E4%B8%80%E7%9A%84%E4%B8%8A%E5%B1%82%E6%8E%A5%E5%8F%A3%E6%98%AF%E5%85%B6%E8%80%83%E8%99%91%E7%9A%84%E4%B8%80%E4%B8%AA%E9%87%8D%E7%82%B9%E3%80%82%E8%80%8CAPR%E6%9C%80%E6%97%A9%E7%9A%84%E7%9B%AE%E7%9A%84%E5%B9%B6%E4%B8%8D%E6%98%AF%E5%A6%82%E6%AD%A4%EF%BC%8C%E5%AE%83%E6%9C%80%E6%97%A9%E5%8F%AA%E6%98%AF%E5%B8%8C%E6%9C%9B%E5%B0%86Apache%E4%B8%AD%E7%94%A8%E5%88%B0%E7%9A%84%E6%89%80%E6%9C%89%E4%BB%A3%E7%A0%81%E5%90%88%E5%B9%B6%E4%B8%BA%E4%B8%80%E4%B8%AA%E9%80%9A%E7%94%A8%E7%9A%84%E4%BB%A3%E7%A0%81%E5%BA%93%EF%BC%8C%E7%84%B6%E8%80%8C%E8%BF%99%E4%B8%8D%E6%98%AF%E4%B8%80%E4%B8%AA%E6%AD%A3%E7%A1%AE%E7%9A%84%E7%AD%96%E7%95%A5%EF%BC%8C%E5%9B%A0%E6%AD%A4%E5%90%8E%E6%9D%A5APR%E6%94%B9%E5%8F%98%E4%BA%86%E5%85%B6%E7%9B%AE%E6%A0%87%E3%80%82%E6%9C%89%E7%9A%84%E6%97%B6%E5%80%99%E4%BD%BF%E7%94%A8%E5%85%AC%E5%85%B1%E4%BB%A3%E7%A0%81%E5%B9%B6%E4%B8%8D%E6%98%AF%E4%B8%80%E4%BB%B6%E5%A5%BD%E4%BA%8B%EF%BC%8C%E6%AF%94%E5%A6%82%E5%A6%82%E4%BD%95%E5%B0%86%E4%B8%80%E4%B8%AA%E8%AF%B7%E6%B1%82%E6%98%A0%E5%B0%84%E5%88%B0%E7%BA%BF%E7%A8%8B%E6%88%96%E8%80%85%E8%BF%9B%E7%A8%8B%E6%98%AF%E5%B9%B3%E5%8F%B0%E7%9B%B8%E5%85%B3%E7%9A%84%EF%BC%8C%E5%9B%A0%E6%AD%A4%E4%BB%85%E4%BB%85%E4%B8%80%E4%B8%AA%E5%85%AC%E5%85%B1%E7%9A%84%E4%BB%A3%E7%A0%81%E5%BA%93%E5%B9%B6%E4%B8%8D%E8%83%BD%E5%AE%8C%E6%88%90%E8%BF%99%E7%A7%8D%E5%8C%BA%E5%88%86%E3%80%82APR%E7%9A%84%E7%9B%AE%E6%A0%87%E5%88%99%E6%98%AF%E5%B8%8C%E6%9C%9B%E5%AE%89%E5%85%A8%E5%90%88%E5%B9%B6%E6%89%80%E6%9C%89%E7%9A%84%E8%83%BD%E5%A4%9F%E5%90%88%E5%B9%B6%E7%9A%84%E4%BB%A3%E7%A0%81%E8%80%8C%E4%B8%8D%E9%9C%80%E8%A6%81%E7%89%BA%E7%89%B2%E6%80%A7%E8%83%BD%E3%80%82%20%20APR%E7%9A%84%E6%9C%80%E6%97%A9%E7%9A%84%E4%B8%80%E4%B8%AA%E7%9B%AE%E6%A0%87%E5%B0%B1%E6%98%AF%E4%B8%BA%E6%89%80%E6%9C%89%E7%9A%84%E5%B9%B3%E5%8F%B0(%E4%B8%8D%E6%98%AF%E9%83%A8%E5%88%86)%E6%8F%90%E4%BE%9B%E4%B8%80%E4%B8%AA%E5%85%AC%E5%85%B1%E7%9A%84%E7%BB%9F%E4%B8%80%E6%93%8D%E4%BD%9C%E5%87%BD%E6%95%B0%E6%8E%A5%E5%8F%A3%EF%BC%8C%E8%BF%99%E6%98%AF%E4%B8%80%E4%B8%AA%E9%9D%9E%E5%B8%B8%E4%BA%86%E4%B8%8D%E8%B5%B7%E7%9A%84%E7%9B%AE%E7%9A%84%EF%BC%8C%E5%BD%93%E7%84%B6%E4%B9%9F%E6%98%AF%E4%B8%8D%E7%8E%B0%E5%AE%9E%E7%9A%84%E4%B8%80%E4%B8%AA%E7%9B%AE%E6%A0%87%E3%80%82%E6%88%91%E4%BB%AC%E4%B8%8D%E5%8F%AF%E8%83%BD%E6%94%AF%E6%8C%81%E6%89%80%E6%9C%89%E5%B9%B3%E5%8F%B0%E7%9A%84%E6%89%80%E6%9C%89%E7%89%B9%E5%BE%81%EF%BC%8C%E5%9B%A0%E6%AD%A4APR%E7%9B%AE%E5%89%8D%E5%8F%AA%E8%83%BD%E4%B8%BA%E5%A4%A7%E5%A4%9A%E6%95%B0%E5%B9%B3%E5%8F%B0%E6%8F%90%E4%BE%9B%E6%89%80%E6%9C%89%E7%9A%84APR%E7%89%B9%E6%80%A7%E6%94%AF%E6%8C%81%EF%BC%8C%E5%8C%85%E6%8B%ACWin32%E3%80%81OS/2%E3%80%81BeOS%E3%80%81Darwin%E3%80%81Linux%E7%AD%89%E7%AD%89%E3%80%82%E4%B8%BA%E4%BA%86%E8%83%BD%E5%A4%9F%E5%AE%9E%E7%8E%B0%E8%BF%99%E4%B8%AA%E7%9B%AE%E6%A0%87%EF%BC%8CAPR%E5%BC%80%E5%8F%91%E8%80%85%E5%BF%85%E9%A1%BB%E4%B8%BA%E9%82%A3%E4%BA%9B%E4%B8%8D%E8%83%BD%E8%BF%90%E8%A1%8C%E4%BA%8E%E6%89%80%E6%9C%89%E5%B9%B3%E5%8F%B0%E7%9A%84%E7%89%B9%E6%80%A7%E5%88%9B%E5%BB%BA%E4%BA%86%E4%B8%80%E7%B3%BB%E5%88%97%E7%9A%84%E7%89%B9%E5%BE%81%E5%AE%8F(FEATURE%20MACROS)%E4%BB%A5%E5%9C%A8%E5%90%84%E4%B8%AA%E5%B9%B3%E5%8F%B0%E4%B9%8B%E9%97%B4%E5%8C%BA%E5%88%86%E8%BF%99%E4%BA%9B%E7%89%B9%E5%BE%81%E3%80%82%E8%BF%99%E4%BA%9B%E7%89%B9%E5%BE%81%E5%AE%8F%E5%AE%9A%E4%B9%89%E9%9D%9E%E5%B8%B8%E7%AE%80%E5%8D%95%EF%BC%8C%E9%80%9A%E5%B8%B8%E7%94%A8APR_HAS_FEATURE%E5%8F%82%E6%95%B0%E8%AE%BE%E7%BD%AE%EF%BC%9A%20%20%E5%A6%82%E6%9E%9C%E6%9F%90%E4%B8%AA%E5%B9%B3%E5%8F%B0%E5%85%B7%E6%9C%89%E8%BF%99%E4%B8%AA%E7%89%B9%E6%80%A7%EF%BC%8C%E5%88%99%E8%AF%A5%E5%AE%8F%E5%BF%85%E9%A1%BB%E8%AE%BE%E7%BD%AE%E4%B8%BAtrue%EF%BC%8C%E6%AF%94%E5%A6%82Linux%E5%92%8Cwindow%E9%83%BD%E5%85%B7%E6%9C%89%E5%86%85%E5%AD%98%E6%98%A0%E5%B0%84%E6%96%87%E4%BB%B6%EF%BC%8C%E5%90%8C%E6%97%B6APR%E6%8F%90%E4%BE%9B%E4%BA%86%E5%86%85%E5%AD%98%E6%98%A0%E5%B0%84%E6%96%87%E4%BB%B6%E7%9A%84%E6%93%8D%E4%BD%9C%E6%8E%A5%E5%8F%A3%EF%BC%8C%E5%9B%A0%E6%AD%A4%E5%9C%A8%E8%BF%99%E4%B8%A4%E4%B8%AA%E5%B9%B3%E5%8F%B0%E4%B8%8A%EF%BC%8CAPR_HAS_MMAP%E5%AE%8F%E5%BF%85%E9%A1%BB%E8%AE%BE%E7%BD%AE%EF%BC%8C%E5%90%8C%E6%97%B6apmmap%E5%87%BD%E6%95%B0%E5%BA%94%E8%AF%A5%E5%B0%86%E7%A3%81%E7%9B%98%E6%96%87%E4%BB%B6%E6%98%A0%E5%B0%84%E4%B8%BA%E5%86%85%E5%AD%98%E5%B9%B6%E8%BF%94%E5%9B%9E%E9%80%82%E5%BD%93%E7%9A%84%E7%8A%B6%E6%80%81%E7%A0%81%E3%80%82%E5%A6%82%E6%9E%9C%E4%BD%A0%E7%9A%84%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E5%B9%B6%E4%B8%8D%E6%94%AF%E6%8C%81%E5%86%85%E5%AD%98%E6%98%A0%E5%B0%84%EF%BC%8C%E9%82%A3%E4%B9%88APR_HAS_MMAP%E5%BF%85%E9%A1%BB%E8%AE%BE%E7%BD%AE%E4%B8%BA0%EF%BC%8C%E8%80%8C%E4%B8%94%E6%89%80%E6%9C%89%E7%9A%84apmmap%E5%87%BD%E6%95%B0%E4%B9%9F%E5%8F%AF%E4%BB%A5%E4%B8%8D%E9%9C%80%E8%A6%81%E5%AE%9A%E4%B9%89%E3%80%82%E7%AC%AC%E4%BA%8C%E6%AD%A5%E5%B0%B1%E6%98%AF%E5%AF%B9%E4%BA%8E%E9%82%A3%E4%BA%9B%E5%9C%A8%E7%A8%8B%E5%BA%8F%E4%B8%AD%E4%BD%BF%E7%94%A8%E4%BA%86%E4%B8%8D%E6%94%AF%E6%8C%81%E7%9A%84%E5%87%BD%E6%95%B0%E5%BF%85%E9%A1%BB%E6%8F%90%E5%87%BA%E8%AD%A6%E5%91%8A%E3%80%82%20%20%E8%A7%A3%E5%86%B3%E6%96%B9%E6%B3%95:%20%20http:/archive.apache.org/dist/tomcat/tomcat-connectors/native/%20%E4%B8%8B%E8%BD%BD) 

假设你不清楚版本,你随便下载多个本子,放进目录里面,在重启tomcat
的时候,会有提示您方便的 tcnative-一.dll 版本。

 

1.

图片 2

 

2.

图片 3

3.

图片 4

4.

图片 5