对象被多个用户共用仍要编译吗

A. 一个关于java的问题，如果成员属性i 被static修饰，i属性被多个对象共用共用的话，static属性i 在内存中

静态是属于类的，比如你使用不同的对象操纵相同的非静态函数，其参数或者操作结果是分开的，也就是你说的不同的内存地址，而如果是静态函数，那就是相同的，也就是说，静态的东西是类下面所有的对象共有的，好像地球是静态的，是属于人类这个类的，而类中的每一个对象“人”对地球做一个什么事情，其他的对象也同时会得到反馈，而电脑不是静态的，每个人都有一部，你家的电脑坏了，别人家的没事
属性也是一样

B. 目标被多个用户共用，仍然编写吗

你说的这个被大家调用的对象他始终都是同一内存地址，所谓多线程，其实还是一个单线程，只是几个线程方法的级别一样高，所以执行一会这个再执行一会其它线程。就好像有一碗粥，三个人分，单线程的情况下可能第一个人都给吃完了，二三个人没有的吃了，如果多线程的话，一人一口，轮着吃，大家都有吃到的机会了。但是粥始终是那一碗粥。
线程的生命周期java基础的书上都有写。
不知道我说的你能明白不。

哦，对，你说的这个一个对象被多个线程调用，如果线程做了休眠或者其它的处理，还可能还存在死锁的问题。出现无法执行的现象

C. java对象调用静态方法为什么会增加编译成本

不管是静态方法还是非静态方法，都需要调用后执行，也就是声明的时候只是在栈内存中存了一个引用,堆内存中并没有分配存储空间,执行的时候才加载到堆内存中...
其执行的次序和在类里声明的次序无关，区别是静态方法是“class.method"方式执行，非静态方法是"object.method"方式执行，即后者需要创建一个对象。
所以就有一个问题,对象是执行的时候才真正加载到内存中去,但是非静态方法执行后,若不会再使用则会被垃圾回收器回收,释放内存
而静态方法加载且只加载一次,所有对象都共用这独一份,因此会一直放在内存中,消耗内存资源...

D. Java创建对象是在编译时还是在运行时

运行期。编译好的java程序(即.class文件)需要运行在JVM中。程序，无论代码还是数据，都需要存储在内存中。JVM为java程序提供并管理所需要的内存空间。JVM内存分为"堆"、"栈"、"方法区"三个区域，分别用于存储不同数据。首先JVM会检查创建这个对象的类是否是一个以前从没有见过的类型，如果不是，JVM将为其分配内存，如果是，java虚拟机将调用具体的ClassLoader找到对应的.class文件，并将这个文件的内容读到内存中去。
1)堆:
1.1)用于存储所有new出来的对象(包括成员变量)。
1.2)垃圾:没有任何引用所指向的对象。
垃圾回收器(GC)不定时到内存中清扫垃圾，
并不一定一发现垃圾就立刻回收，
回收过程是透明的(看不到的)，
通过调用System.gc()可以建议虚拟机尽快调度GC来回收。
1.3)内存泄漏:不再使用的内存没有被及时的回收。
建议:不再使用的对象，及时将引用设置为null。
1.4)成员变量的生命周期:
创建对象时存储在堆中，对象被回收时一并被回收。
2)栈:
2.1)用于存储正在调用的方法中的所有局部变量(包括参数)
2.2)JVM会为每一个正在调用的方法分配一块对应的栈帧，
栈帧中存储方法中的局部变量(包括参数)，
方法调用结束时，栈帧被清除，局部变量一并被清除。
2.3)局部变量的生命周期:
调用方法时存在栈中，方法结束时与栈帧一并被清除。
3)方法区:
3.1)用于存储.class字节码文件(包括方法)。
3.2)方法只有一份，通过this来区分具体的对象。
既然对象在堆中创建，因此Java创建对象是在运行时，而不是编译时。

E. C++这里构造函数带有形参，建立对象没有给出初始值，但编译器没有提示出错，为什么

不会的。
c++类的构造函数详解
一、构造函数是干什么的

classCounter
{

public:
//类Counter的构造函数
//特点：以类名作为函数名，无返回类型
Counter()
{
m_value=0;
}

private:

//数据成员
intm_value;
}


该类对象被创建时，编译系统对象分配内存空间，并自动调用该构造函数->由构造函数完成成员的初始化工作

eg:Counterc1;
编译系统为对象c1的每个数据成员(m_value)分配内存空间，并调用构造函数Counter()自动地初始化对象c1的m_value值设置为0

故：

构造函数的作用：初始化对象的数据成员。


二、构造函数的种类

classComplex
{

private:
doublem_real;
doublem_imag;

public:

//无参数构造函数
//如果创建一个类你没有写任何构造函数,则系统会自动生成默认的无参构造函数，函数为空，什么都不做
//只要你写了一个下面的某一种构造函数，系统就不会再自动生成这样一个默认的构造函数，如果希望有一个这样的无参构造函数，则需要自己显示地写出来
Complex(void)
{
m_real=0.0;
m_imag=0.0;
}

//一般构造函数（也称重载构造函数）
//一般构造函数可以有各种参数形式,一个类可以有多个一般构造函数，前提是参数的个数或者类型不同（基于c++的重载函数原理）
//例如：你还可以写一个Complex(intnum)的构造函数出来
//创建对象时根据传入的参数不同调用不同的构造函数
Complex(doublereal,doubleimag)
{
m_real=real;
m_imag=imag;
}

//复制构造函数（也称为拷贝构造函数）
//复制构造函数参数为类对象本身的引用，用于根据一个已存在的对象复制出一个新的该类的对象，一般在函数中会将已存在对象的数据成员的值复制一份到新创建的对象中
//若没有显示的写复制构造函数，则系统会默认创建一个复制构造函数，但当类中有指针成员时，由系统默认创建该复制构造函数会存在风险，具体原因请查询有关“浅拷贝”、“深拷贝”的文章论述
Complex(constComplex&c)
{
//将对象c中的数据成员值复制过来
m_real=c.m_real;
m_img=c.m_img;
}

//类型转换构造函数，根据一个指定的类型的对象创建一个本类的对象
//例如：下面将根据一个double类型的对象创建了一个Complex对象
Complex::Complex(doubler)
{
m_real=r;
m_imag=0.0;
}

//等号运算符重载
//注意，这个类似复制构造函数，将=右边的本类对象的值复制给等号左边的对象，它不属于构造函数，等号左右两边的对象必须已经被创建
//若没有显示的写=运算符重载，则系统也会创建一个默认的=运算符重载，只做一些基本的拷贝工作
Complex&operator=(constComplex&rhs)
{
//首先检测等号右边的是否就是左边的对象本，若是本对象本身,则直接返回
if(this==&rhs)
{
return*this;
}

//复制等号右边的成员到左边的对象中
this->m_real=rhs.m_real;
this->m_imag=rhs.m_imag;

//把等号左边的对象再次传出
//目的是为了支持连等eg:a=b=c系统首先运行b=c
//然后运行a=(b=c的返回值,这里应该是复制c值后的b对象)
return*this;
}

};

下面使用上面定义的类对象来说明各个构造函数的用法：

voidmain()
{
//调用了无参构造函数，数据成员初值被赋为0.0
Complexc1，c2;

//调用一般构造函数，数据成员初值被赋为指定值
Complexc3(1.0,2.5);
//也可以使用下面的形式
Complexc3=Complex(1.0,2.5);

//把c3的数据成员的值赋值给c1
//由于c1已经事先被创建，故此处不会调用任何构造函数
//只会调用=号运算符重载函数
c1=c3;

//调用类型转换构造函数
//系统首先调用类型转换构造函数，将5.2创建为一个本类的临时对象，然后调用等号运算符重载，将该临时对象赋值给c1
c2=5.2;

//调用拷贝构造函数(有下面两种调用方式)
Complexc5(c2);
Complexc4=c2;//注意和=运算符重载区分,这里等号左边的对象不是事先已经创建，故需要调用拷贝构造函数，参数为c2

}

F. 用户管理系统 - 用户权限设计(RBAC模型）

权限管控可以通俗的理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。

Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。

原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。

例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。

缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。

Discretionary Access Control，DAC是ACL的一种拓展。

原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。

例如：常见于文件系统，linux，UNIX、WindowsNT版本的操作系统都提供DAC的支持。

缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。

Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。

原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。

例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

(Attribute-Based Access Control)，能很好地解决RBAC的缺点，在新增资源时容易维护。

原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。

属性通常有四类：

例如：早上9:00 11:00期间A、B两个部门一起以考生的身份考试，下午14:00 17:00期间A、B两个部门相互阅卷。

缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。

RBAC的核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。

RBAC三要素：

在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。

RBAC模型可以分为：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相当于底层逻辑，后三者都是在RBAC 0模型上的拔高。

我先简单介绍下这四个RBAC模型：

RBAC 0模型： 用户和角色、角色和权限多对多关系。

简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。

RBAC 0模型如下图：没有画太多线，但是已经能够看出多对多关系。

RBAC 1模型： 相对于RBAC 0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如role1根节点下有role1.1和role1.2两个子节点。

角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过BD工具（类CRM），BD之间就有分级（经理、主管、专员），如果采用RBAC 0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。

而RBAC 1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。

RBAC 1模型如下图：多对多关系仍旧没有改变，只增加角色分级逻辑。

[图片上传中...(-95cc0-1640060170347-0)]

RBAC 2模型： 基于RBAC 0模型，对角色增加了更多约束条件。

如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。

如角色数量限制，例如：一个角色专门为公司CEO创建的，最后发现公司有10个人拥有CEO角色，一个公司有10个CEO？

这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。

RBAC 2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。

RBAC 3模型： 同样是基于RBAC0模型，但是综合了RBAC 1和RBAC 2的所有特点。这里就不在多描述，读者返回去看RBAC 1和RBAC 2模型的描述即可。

RBAC 权限模型由三大部分构成，即用户管理、角色管理、权限管理。用户管理按照企业架构或业务线架构来划分，这些结构本身比较清晰，扩展性和可读性都非常好。角色管理一定要在深入理解业务逻辑后再来设计，一般使用各部门真实的角色作为基础，再根据业务逻辑进行扩展。权限管理是前两种管理的再加固，做太细容易太碎片，做太粗又不够安全，这里我们需要根据经验和实际情况来设计。

用户管理中的用户，是企业里每一位员工，他们本身就有自己的组织架构，我们可以直接使用企业部门架构或者业务线架构来作为线索，构建用户管理系统。

需要特殊注意：

实际业务中的组织架构可能与企业部门架构、业务线架构不同，需要考虑数据共享机制，一般的做法为授权某个人、某个角色组共享某个组织层级的某个对象组数据。

在设计系统角色时，我们应该深入理解公司架构、业务架构后，再根据需求设计角色及角色内的等级。一般角色相对于用户来说是固定不变的，每个角色都有自己明确的权限和限制，这些权限在系统设计之处就确定了，之后也轻易不会再变动。
（1）自动获得基础角色
当员工入职到某部门时，该名员工的账号应该自动被加入该部门对应的基础角色中，并拥有对应的基础权限。这种操作是为了保证系统安全的前提下，减少了管理员大量手动操作。使新入职员工能快速使用系统，提高工作效率。

（2）临时角色与失效时间

公司业务有时需要外援来支持，他们并不属于公司员工，也只是在某个时段在公司做支持。此时我们需要设置临时角色，来应对这种可能跨多部门协作的临时员工。

如果公司安全级别较高，此类账号默认有固定失效时间，到达失效时间需再次审核才能重新开启。避免临时账号因为流程不完善，遗忘在系统中，引起安全隐患。

（3）虚拟角色

部门角色中的等级，可以授权同等级的员工拥有相同的权限，但某些员工因工作原因，需要调用角色等级之外的权限，相同等级不同员工需要使用的权限还不相同。这种超出角色等级又合理的权限授予，我们可以设置虚拟角色。这一虚拟角色可集成这一工作所需的所有权限，然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色，也可以满足工作中特殊情况的权限需求。

（4）黑白名单

白名单：某些用户自身不拥有某部门的顶级角色，但处于业务需求，需要给他角色外的高级权限，那么我们可以设计限制范围的白名单，将需要的用户添加进去即可。在安全流程中，我们仅需要对白名单设计安全流程，即可审核在白名单中的特殊用户，做到监控拥有特殊权限的用户，减少安全隐患。

黑名单：比较常见的黑名单场景是某些犯了错误的员工，虽然在职，但已经不能给他们任何公司权限了。这种既不能取消角色关联，也不能完全停用账号的情况，可以设置黑名单，让此类用户可以登录账号，查看基本信息，但大多数关键权限已经被黑名单限制。

权限管理一般从三个方面来做限制。页面/菜单权限，操作权限，数据权限。

（1）页面/菜单权限
对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。

（2）操作权限
操作权限通常是指对同一组数据，不同的用户是否可以增删改查。对某些用户来说是只读浏览数据，对某些用户来说是可编辑的数据。

（3）数据权限
对于安全需求高的权限管理，仅从前端限制隐藏菜单，隐藏编辑按钮是不够的，还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据，服务器端会识别、记录并限制访问。

数据权限如何管控

数据权限可以分为行权限和列权限。行权限控制：看多少条数据。列权限控制：看一条数据的多少个字段
简单系统中可以通过组织架构来管控行权限，按照角色来配置列权限，但是遇到复杂情况，组织架构是承载不了复杂行权限管控，角色也更不能承载列的特殊化展示。

目前行业的做法是提供行列级数据权规则配置，把规则当成类似权限点配置赋予某个角色或者某个用户。

网易有数做法：
https://youdata.163.com/index/manual/o/6System_management/data_role.html

1.超级管理员
超级管理员是用来启动系统，配置系统的账号。这个账号应该在配置好系统，创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限，可穿梭查看各部门数据，如果使用不恰当，是系统管理的安全隐患。

2.互斥角色如何处理
当用户已经有用的角色和即将添加的角色互相互斥时，应该在添加新角色时，提示管理员因角色互斥的原因，无法进行新角色添加。如需添加，要先撤销掉前一个角色，再添加新角色。

3.用户管理权限系统设计一定要简单清晰
在设计权限系统之处，一定要理清思路，一切从简，能不增加的多余角色和权限逻辑，就一定不要增加。因为随着公司业务的扩大，权限和角色也会随之增多，如果初期设计思路不严谨，那么权限系统会随着业务的扩大而无限混乱下去，此时再来整理权限，已经太晚了。所以初期设计就一定要条理清晰，简单明了，能避免后续非常多不必要的麻烦。

4.无权提示页
有时员工 A 会直接给员工 B 分享他当下正在操作的页面，但有可能员工 B 无权查看。此时我们应该在这里考虑添加“无权提示页”，避免粗暴的 404 页面让员工 B 以为是系统出错了。

G. 请问高手！

EJB
中科永联高级技术培训中心（www.itise.com）

EJB (Enterprise JavaBean)是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。

在J2EE里，Enterprise Java Beans(EJB)称为Java 企业柄，是Java的核心代码，分为整体柄和片段柄和消息柄三个部分，其中的消息柄将在以后再作讨论。现在我们来看看什么是整体柄和片段柄。

整体柄是一种对象: 标准Java对象由创建它的程序创建，当程序终止时，对象也随之丢失，这就意味着当再次运行些程序时，将无法找到先前创建的柄，而整体柄会一直存在着直到它被删除。 一个程序可以创建一个整体柄，并且这个程序可以在被保存后随时停止和重启。整体柄将会依然存在。重启后，程序可以找到与之相对应的整体柄，并且会继续使用这个整体柄。

EJB实际上是SUN的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品.EJB是BEANS,BEANS是什么概念,那就是得有一个容纳她,让她可劲造腾的地方,就是得有容器.EJB必须生存在EJB容器中.这个容器可是功能强大之极!她首先要包装你BEAN,EJB的客户程序实际上从来就不和你编写的EJB直接打交道,他们之间是通过HOME/REMOTE接口来发生关系的.它负责你的BEAN的所有的吃喝拉萨睡,比如BEAN的持续化,安全性,事务管理...

一.什么是 EJB?

一个技术规范：EJB 从技术上而言不是一种"产品"
EJB 是一种标准描述了构建应用组件要解决的:
可扩展 (Scalable)
分布式 (Distributed)
事务处理 (Transactional)
数据存储 (Persistent)
安全性 (Secure)

二.Sun 对 EJB 的期望

提供一个标准的分布的、基于 OO 的组件架构
屏蔽复杂的系统级功能需求
Write once, run anywhere
与非 Java 应用之间的互操作能力
兼容 CORBA 标准

三.为什么选择 EJB?

EJB 服务器完成"繁杂"的工作：应用开发人员关注于业务逻辑的实现而不是底层的实现机制(类似于 4GL 语言设计的目标)
支持事务处理
多个业务操作同时成功，或全部失败
可以通过在代码外的描述来定义事务处理级别
可扩展性
EJB 可以根据您应用的增长而扩展
EJB 服务器往往还提供了负载均衡和
安全性：由 EJB 服务器提供资源的访问权限控制

四.EJB 架构

为了满足架构的目标，规范中描述了
服务器 (Server)
容器 (Container)
类 (Class) 和实例 (Instance)
Home 和 Remote 接口
客户端 (Client)

五. 简化的编程模型

关注于业务逻辑实现：EJB 负责生命周期 (lifecycle), 数据存储 (persistence), 事务处理语义 (transactional semantic), 安全(security), ...
通用的编程模型：各种服务的高层 API
Java 是其编程语言

1.EJB 特点

由一个 EJB 容器在运行时创建和管理 EJB
在部署 EJB 时定制其运行方式
由 EJB 容器和服务器来协调客户端的访问
可以部署到任何兼容的 EJB 容器中
客户端对 EJB 的视图是由 Bean 开发人员决定的

2.EJB 服务器

管理 EJB 容器 (它管理 Bean)
提供对操作系统服务的存取
提供 Java 相关的服务，尤其是
通过 JNDI 访问命名空间
基于 OTS 的事务处理服务

3.EJB 容器

管理 Bean 生命周期：将 EJB 服务器提供的服务传递给 Bean
生成代码来实现对 Bean 的存取访问
强制事务处理的限制
创建、初始化和回收 Bean
管理持久数据的存储
对客户端而言 EJB 容器是透明的

4.在一个 EJB 服务器中的容器

目前容器通常是由 EJB 服务器本身提供的
在 EJB 1.0 或 1.1 规范中没有定义容器-到-服务器的接口
各厂商可以根据他们的见解来实现服务器和容器的各自责任

5.容器提供服务: 数据存储

容器决定何时载入/储存状态
Container-Managed Persistence(容器管理存储/CMP)
容器负责存储您的 Bean
容器生成必要的类和代码
Bean-Managed Persistence(Bean 管理存储/BMP)
Bean 开发人员提供存储代码
开发人员决定 如何存储, 容器仍然决定 何时进行

6.容器提供服务: 事务处理

可以由容器代理来实现
容器将得到业务逻辑方法的事务处理需求
容器提供事务控制代码
也可以由程序员通过代码实现

7.容器提供服务: 其它服务

其它服务包括
命名 (Naming)
安全 (Security)
线程管理 (Thread management)
这些服务由容器代理完成将减少应用开发人员的负担

8.分布式对象运算

远程对象被作为本地对象来处理：传递信息的方式不变，但开销更大
Enterprise JavaBeans 永远运行在服务器上：对 Bean 的访问永远是远程调用

9.Stub 和 Skeleton

由 EJB 生成:
"Stub" 对要传递出去的信息编码
"Tie/Skel" 将接受到的信息解码并传递给目标对象

10.分类: Enterprise JavaBeans

+---Entity Beans--CMP/BMP
Ejb--|
+---Session Beans--Stateful/Stateless

会话 Bean (Session Bean)：根据 EJB 规范，一个会话 Bean 是:

代表单个客户端来执行
可以参与到事务处理中
不直接代表共享于数据库中的数据，但它能访问和更新这些数据
相对而言是短暂存在的
当 EJB 容器失效后就不存在－－－客户端需要重新建立一个信新的会话对象来继续运算

实体 Bean (Entity Bean)：根据 EJB 规范，一个实体 Bean 是:

提供在数据库中数据的对象视图
允许被多个用户共享存取访问
可以是长期存在 (只要它存在于数据库中)
实体 Bean, 它的主键对象, 以及它的远程引用将能跨 EJB 容器的宕机而存在

11.EJB 类和实例

构建 EJB 应用包括来自三方的代码
开发人员编写的代码
由 EJB API 定义的类和接口
由容器自动生成的代码
开发人员编写的代码包括
Bean 类 (定义了业务逻辑)
Home 接口 (如何查找或创建 bean)
Remote 接口 (如何存取 bean)
其它组件，根据 bean 实际要求

12.EJB Home 接口

每个 bean 有一个
用于:创建新的 bean 实例、查找现存的 bean (只能是实体 bean)

Remote 接口：定义 bean 的公共接口－－－只有在 Remote 接口中定义的方法才能被客户端访问

EJB 客户端

可以为 servlet, JSP, 应用程序或其它 bean
通过 JNDI 来查找 EJB home 接口，步骤为:
创建一个 JNDI Context (initial context)
使用 JNDI Context 来查找 bean home 接口
使用 bean home 接口来创建/查找 bean 实例
使用 bean 实例完成业务操作
实际的存取 (对 EJB) 是通过容器生成的类来完成

EJB 架构

客户端对 bean 访问永远不是直接的
EJBObject (tie) 是由容器自身提供的：用来帮助管理 bean 的生命周期

EJB 中的角色

EJB 服务器供应商: 开发并销售 EJB 服务器
EJB 容器供应商: 开发并销售 EJB 容器
Enterprise bean 开发人员: 开发并销售 EJB
应用组装人员: 将不同的 EJB 搭建成应用

六、EJB的体系结构

目前，EJB最新的标准是2.1，EJB3.0规范正在讨论中，预计将于明年推出。EJB2.1定义了三种企业Bean，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。

Session Bean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个Session Bean来为客户端服务。Session Bean可以直接访问数据库，但更多时候，它会通过Entity Bean实现数据访问。

Entity Bean是域模型对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象，事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。

MessageDriven Bean是EJB2.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步的无状态Session Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。

调用一个EJB组件要比调用一个JavaBean麻烦些，由于EJB组件可以分布在多台服务器上，因此必须首先获得远程或本地Home接口，然后使用Home接口创建EJB之后就可以调用EJB的方法了。

七、EJB设计模式

常见EJB设计模式

SESsion Facade pattern

通常项目中，客户端往往需要频繁的对服务器端数据进行操作。当采用实体EJB作为数据的抽象层时，如果直接让客户端程序与实体EJB交互，会产生实现一个业务需求便需要大量的EJB属性操作（如下图1）。这直接导致如下问题：网络负载大（远程客户端时）、并发性能低、客户端与服务器端关联度大、可重用性和可维护性差、性能
因此有必要在客户端与实体EJB层间加入Session EJB层，在Sessino EJB中实现商业逻辑并封装对实体EJB的操作。（如下图2）

图1：客户端直接与实体EJB交互

图2：通过SessionEJB层实现

Session Facade模式的好处是：降低了网络负载，SessionEjb可以调用实体EJB的本地接口；将商业逻辑与商业数据隔离；维护与开发方便；显着提高性能。

Session Facade模式因其简单使用，是目前使用很广的模式。但具体应用过程中应注意：避免将所有的操作封装到一个很大的SessionEJB内；服务器端数据结构应由实体EJB实现,除非特例否则避免直接的数据库操作；SessionEjb内某些系统通用操作的代码容易重复（比如权限检查等，解决办法是将系统通用服务封装在Java Class内）。

MesSAge Facade Pattern

很多时候，一次RequeST需要操作多个EJB又不需要得到即时返回。对这种异步调用，通常应用Message Fa?ade Pattern.

这种时候，如采用Session Fa?ade Pattern存在如下问题：
1. 客户端等待返回的时间过长。一个SessionEjb的实例在完成客户请求过程中中涉及到的每一次对其他实体Ejb的调用过程中都会被锁定直到得到实体EJB返回信息后才能进行下一步操作。这样造成客户不必要的等待，并很容易因时间导致整个事务失败。
2. 系统可靠性和容错性低。如果需要调用不同系统或服务器上或多个异构数据源的多个EJB时，任何一个环节出错，均导致客户请求失败。
以Message-Driven Bean为基础的Message Facade Pattern则可以解决上述异步请求需求。具体架构见下图3

图3：使用Message Facade Pattern

Message Facade Pattern的不足之处在于：
1． Message-Driven Bean没有返回值。这样通知客户执行结果只能依赖于EmAIl或人工等其他手段。
2． Message-Driven Bean执行过程中无法将捕获的异常直接返回给客户端，即无法使客户端直接直到错误信息。
3． Message-Driven Bean通过接收Message响应客户请求，对Message内容的合法性（比如对象的类型等）依赖与客户端.容易产生运行时错误。
Message Facade Pattern经常与Session Facade Pattern在同一个项目里共同使用。

EJB Command Pattern

Session Facade Pattern中将商业逻辑实现封装在Session EJB中，这种做法带来诸多益处之外也带来如下问题：

1． 由于业务经常的变化，导致经常需要更新Session EJB代码。
2． 客户端代码不得不包含大量EJB相关的API，不利于后期项目维护。
3． 项目开发测试需要经常的EJB重部署过程。

引起上述问题的重要根结就是Session EJB本身重量级组件，其开发测试部署工作量较大，开发周期较长。以上不足可以通过EJB Command Pattern克服。

EJB Command Pattern中将商业逻辑实现封装在普通的Java ClASs（称之为Command Bean）中。该模式的具体实现有很多种，通常的框架都包括三部分：

1． Command Bean.由应用开发者写的具体实现某商业操作的Java Class.主要包含getXXX(),setXXX(),exECute()方法。
2． Client-Side Routing Logic.由多个Class组成，用于将请求转发至Command Sever，这个过程对客户是透明的。这部分代码可以跨项目使用。路由规则中可以考虑用XML技术。
3． Remote Command Server.实际执行商业操作请求。通常可以用Session EJB层实现。

整个框架见下图4：

图4：Command的基本框架

EJB Command Pattern具有如下好处：

1． 适应与需要快速开发环境。因Command Bean是轻量级的Java Class，其编译和调试比较方便。
2． 将表现层与商业实现层隔离，同时将客户端代码与EJB层隔离。
3． 将客户端代码开发与服务器端代码开发相对清晰。早期可以创建空的Command Bean方便客户端代码调试。

EJB Command Pattern的弱处在于：
1． Command Bean中对事务的控制不如Session EJB中。
2． Command Bean是无状态的。
3． 无法将异常直接返回给客户。
4． 在大项目中，由于商业逻辑复杂，常导致大数量的Command Bean存在.
5． 作为Command Server的Session EJB打包时必须包含Command Bean以致存在维护上的不便。

EJB Command Pattern的一个实际实现可以参考IBM's Command framework.

Data Transfer object Factory

基于EJB的J2EE项目，经常需要在客户端与服务器端传输大量数据。数据的组织形式常用的是DTO(Data Transfer Object，服务器端数据对象的抽象)。但因为客户端表现层经常是变化的，所需要服务器端数据也变动频繁，换句话说，DTO的数量和属性经常要更改。因此如何以及在何处生成和维护DTO便是需要考虑的问题。

一种解决方案是直接在Entity EJB中直接处理，即在Entity EJB的Bean类中加入getXXXDTO()、setXXXDTO()等。但这样做导致EJB与DTO层紧紧绑定。一旦DTO更改，与该DTO相关的EJB即需要重编译打包。EJB层与客户端层相关联不仅使维护困难而且导致EJB的重用性大大降低。

更好的解决方案是利用Data Transfer Object Factory封装对DTO的操作逻辑（如下图6）。

图6：DTO Factory示例

DTO Factory具体实现方式通常有两种：

1． 普通Java Class实现，用于Session Facade Pattern使用DTO环境下。
2． Stateless Session EJB实现，用于非EJB客户端使用DTO环境下（见图7）。

图7：SessionEJB实现DTOFactory

DTO Factory带来如下好处：

1． 使Entity EJB的重用成为可能。由于不含DTO处理逻辑，Entity EJB功能单一化，只作为数据源。不通客户端通过各自的DTO Factory可以从同一个Entity EJB得到各自所需的个性化数据（自定义DTO）。
2． 提高可维护性和性能。
3． 可以根据在DTO Factory层生成很复杂的DTO结构，诸如继承、关联关系等，而对客户端提供一个透明、细化的数据接口。

使用DTO Factory时需要注意的是：不需为每个Entity EJB定义一个Factory。可以为一系列相关的Entity EJB创建一个Factory，或者只创建一个Factory。

Generic Attribute Access

使用Entity EJB作为商业数据层时，我们首先需要从数据库加载数据，创建对应的Entity EJB实例，之后对内存中Entity EJB实例的属性进行相应操作。对属性的操作比较直接的做法是：直接调用Entity EJB的getXXX()/setXXX()，通常利用EJB2.0的本地接口；通过DTO Factory生成DTO。但这两种做法都存在如下问题：

1． 当Entity EJB的属性特别多时候，以上做法会带来复杂罗嗦的代码，使EJB变的庞大无比。
2． 使Entity EJB的客户端（比如Session EJB）和Entity EJB的接口紧密关联。Entity EJB属性的增删都需要更改客户端代码，给项目开发和维护带来不便。

事实上可以利用更通用的方式访问Entity EJB的属性，即定义Generic Attribute Access Interface。见下图8：

图8：Generic Attribute Access Interface示例

Generic Attribute Access Interface由Entity EJB的本地或远程接口实现，并利用Hash Maps传输数据。实现方式常见如下：

1． BMP类型实体EJB可以在Bean类中定义包含所有属性的私有成员变量HashMap。
2． CMP类型实体EJB可以在Bean类中可以适用Java Reflection API实现。
3． 建立一个父类，在不同的情况下定义子类重载父类方法。
使用Generic Attribute Access Interface需要在客户端与服务器端对属性以及对应的关键字建立统一的命名习惯。常见的做法如下：
1． 建立并保持良好的文档记录和命名约定。
2． 在实体EJB的实现类中定义静态成员映射属性。
3． 创建共享静态类，通过成员变量映射实体EJB属性。
4． 通过JNDI在服务器端保存属性映射关系。
Generic Attribute Access Interface的运用带来一下益处：
1． 接口实现后对不通实体EJB都适用。
2． 对属性较多实体EJB能精简代码，并更具维护性。
3． 使运行中动态增删实体EJB属性成为可能。
Generic Attribute Access Interface的缺点在于：
1． 访问EJB属性时增加了额外的操作。需要通过关键字映射属性，最后还需进行类型转换。
2． 需要建立客户端与服务器端的命名约定。
3． 因为通过HashMap操作时候需要进行类型转换，容易产生运行时类型不匹配异常。

Business Interface

EJB规范要求Bean实现类必须实现所有在远程（或本地）接口中定义的所有方法，同时不允许Bean实现类直接继承远程（或本地）接口。这就导致编译时候很容易产生两者不一致的问题，即远程（或本地）接口中定义的某方法为在Bean实现类中被实现等错误。为避免上诉错误，可以利用应用服务器厂商所提供的工具。但也可以应用EJB的设计架构来实现：定义商业接口。
Business Interface即创建自定义商业接口，在接口中定义所有EJB提供的商业方法，并让Bean实现类和远程（或本地）接口都实现该商业接口。其继承关系见下图9：

图9：商业接口的使用

Business Interface是个普通的Java Class。依赖于使用本地接口与远程接口的不通，Business Interface的定义略有不同：应用与远程接口时，在接口中的方法需要抛出java.rmi.RemoteException；而应用与本地接口时候则不需要作任何特别处理。
应用Business Interface时候必须注意一点：EJB规范不允许直接EJB的实例将对自己的引用（this对象）返回给客户端，否则编译时候即报错。但使用Business Interface后，编译时候无法检查出有无将this对象返回给客户端。这一点需要程序员自己保证。

三． 内部数据转换策略

Data Transfer Object

基于EJB的J2EE多层架构应用中，经常涉及的一个问题就是如何在各层之间传递批量数据，比如客户端对服务器端数据的批量读写操作等。比如需要得到实体EJB的属性，直接的方法是多次调用不通的属性，如下图10：

图10：低效的数据传递方式

但这种方法容易导致许多问题，比如性能以及代码的复杂度等，更有效的办法是在一个调用中得到所有需要的属性。所以可以引入Data Transfer Object来封装所需要的属性，并在客户与服务器端通过传递该对象一次实现对数据的操作。如下图11：

图11：通过DTO传递数据

DTO为普通的Java Class，通常是服务器端数据的快照。由于网络传输的需要，DTO应该实现java.io.Serializable接口。
DTO的设计有两种模型：Domain DTO以及Custom DTO。
Domain DTO仅仅实现对服务器数据的拷贝，通常与实体EJB为一对一的关系(也存在为多个相关联的实体EJB对应一个Domain DTO)。Domain DTO通常除用于读取更改实体EJB属性外也可用于创建实体EJB时候。实体EJB与Domain DTO对应关系如下图12：

图12：Account EJB 与 Account DomainDTO

Domain DTO的应用除了DTO所具有的一般优点外，还有别的益处：

1． 开发迅速。因为一旦实体EJB设计好后，很容易转换得到Domain DTO。
2． 可以利用Domain DTO的setXXX()方法在客户端进行属性有效性效验。
Domain DTO的缺点有：
1． 客户端绑定了服务器端数据模型，不利于维护。
2． 不够灵活，无法处理客户端的多样化数据要求。对一个数百个属性的实体EJB请求一个属性时候却返回一个包含所有属性值的Domain DTO明显是笨重的实现。
3． 导致代码的重复。
4． Domain DTO中如果嵌套包含了别的Domain DTO时，一旦需服务器端数据的更改而需要重定义Domain DTO模型时候异常困难。

Custom DTO则可以克服上述的一些缺点。Customer DTO仅仅封装用户感兴趣的服务器数据集即可以根据客户端需求创建Customer DTO。这样作的优点是灵活高效；缺点是大项目中可能导致大量的Customer DTO存在。

通常Domain DTO可以用于数据的更新与创建；Customer DTO可以用于客户用于表现层的数据读取。两者可以相辅相成。而且使用DTO一般与DTO Factory同时使用。

Domain Transfer Hash Map

DTO的使用往往缺乏通用性。不通的用户案例需要创建不同的DTO。当项目很复杂时，从维护性考虑需要更好的数据传输的实现方式。
Domain Transfer Hash Map即利用HashMap作为客户所需数据集的封装。好处是：

1． 良好的维护性。
2． 较大的通用性。不同的客户端可以使用相同的数据传递方式。
缺点是：
1． 需要维护客户端与服务器端在属性及其对应关键字的映射关系。
2． 当需要使用基本类型的数据时候，因为Hash Map的限制必须将基本类型先转换成对象。
3． 使用得到的数据时，需要进行类型强制转换。

Data Transfer RowSet

当需要处理直接的JDBC调用得到的结果集时，显然用DTO/Hash Map已经不合适，因为需要对大量数据进行类型转换等额外操作是很费资源和不必要的，而且最终用户常需要以表格式样显示数据。

所以对二维表式数据，更好的处理方式是利用Data Transfer RowSet。Data Transfer RowSet通过将ResultSet直接转换为RowSet传递给客户端。
在Session EJB中使用RowSet的一段示例代码如下图13：

图13：使用RowSet

使用RowSet的好处很多：
1． 接口通用于各样的数据库查询操作。
2． 当需要表格式数据显示时，因为直接从ResultSet得到，所以不需要额外的数据类型转换。
缺点是：
1． 数据库结构暴露给客户端。
2． 不符合面向对象设计思想。
3． 依赖于SQL。
Data Transfer RowSet通常用于只读式数据的显示操作，经常和JDBC for Reading Pattern连用。

四．事务和数据持久机制

JDBC for Reading Pattern

基于EJB的J2EE应用中，通过EJB对数据库的操作可以有两种方式：实体EJB或者Session EJB中直接利用JDBC访问。
客户很多时候取出数据库中数据并以表格方式显示。这种情形如果使用实体EJB会导致如下问题：
1． 引用服务器端频繁的数据库查询和加载操作。因为加载N个实体EJB总需要进行一次find()操作N次数据加载。
2． 如果使用Remote接口，引起频繁的额外网络操作。
3． 对关联关系比较复杂的数据库表结构，很难直接通过Entity EJB表现。

因此建议在只需对数据库表数据进行只读访问时候，应该采用JDBC for Reading Pattern，即通过JDBC直接访问数据库。除了避免上述使用实体EJB的缺点还带来一下好处：
1． 充分利用数据库能力，比如数据库的缓存机制。
2． 减少了对事务控制的资源。
3． 利用自定义SQL可以按需要比较灵活的读取数据。
4． 只需要一次数据查询，减少了数据库操作。

缺点是：
1． 于J2EE应用的面向对象设计相违背。
2． 因为Session EJB代码中包含了自定义SQL，维护性差。
3． Session EJB中不得不包含JDBC的API，并且需要了解数据库结构。

部属人员: 使用相应工具在运行环境下配置 EJB
系统管理员: 监视运行时情况

H. c语言既可以编译执行又可以解释执行吗 编译执行怎么解释 解释执行又怎么解释

C 语言程序仅可以解释执行。

解释程序是将源程序(如BASIC)作为输入，解释一句后就提交计算机执行一句，并不形成目标程序。编译程序是把高级语言(如FORTRAN、COBOL、Pascal、C等)源程序作为输入，进行翻译转换，产生出机器语言的目标程序，然后再让计算机执行这个目标程序，得到计算结果。

相对于编译性语言，其优点是可移植性好，只要有解释器环境，程序就可以在不同的操作系统上运行。

缺点是代码需要有专门的解释器，在程序运行时，除要给用户程序本身分配内存空间外，解释器也占用系统资源，所以其运行速度较慢。另外，也很难达到像C、C++那样操作系统底层操作的目的。

解释型语言常用于，一是对运行速度要求不高（如一些网页脚本等）的场合，二是对跨平台（操作系统的兼容性）有要求的场合。

(8)对象被多个用户共用仍要编译吗扩展阅读

1、Python和Java语言，专门有一个解释器能够直接执行Python程序，每个语句都是执行的时候才翻译。

2、Python代码在运行前，会先编译成中间代码，每个 .py 文件将被换转成pyc 文件，pyc 就是一种字节码文件，它是与平台无关的中间代码。不管放在 Windows 还是 Linux 平台都可以执行，运行时将由虚拟机逐行把字节码翻译成目标代码。

I. 如何解决java.lang.NoClassDefFoundError

NoClassDefFoundError错误发生的原因

NoClassDefFoundError错误的发生，是因为Java虚拟机在编译时能找到合适的类，而在运行时不能找到合适的类导致的错误。例如在运行时我们想调用某个类的方法或者访问这个类的静态成员的时候，发现这个类不可用，此时Java虚拟机就会抛出NoClassDefFoundError错误。与ClassNotFoundException的不同在于，这个错误发生只在运行时需要加载对应的类不成功，而不是编译时发生。很多Java开发者很容易在这里把这两个错误搞混。

简单总结就是，NoClassDefFoundError发生在编译时对应的类可用，而运行时在Java的classpath路径中，对应的类不可用导致的错误。发生NoClassDefFoundError错误时，你能看到如下的错误日志：

Exception in thread "main" java.lang.NoClassDefFoundError

错误的信息很明显地指明main线程无法找到指定的类，而这个main线程可能时主线程或者其他子线程。如果是主线程发生错误，程序将崩溃或停止，而如果是子线程，则子线程停止，其他线程继续运行。

NoClassDefFoundError和ClassNotFoundException区别

我们经常被java.lang.ClassNotFoundException和java.lang.NoClassDefFoundError这两个错误迷惑不清，尽管他们都与Java classpath有关，但是他们完全不同。NoClassDefFoundError发生在JVM在动态运行时，根据你提供的类名，在classpath中找到对应的类进行加载，但当它找不到这个类时，就发生了java.lang.NoClassDefFoundError的错误，而ClassNotFoundException是在编译的时候在classpath中找不到对应的类而发生的错误。ClassNotFoundException比NoClassDefFoundError容易解决，是因为在编译时我们就知道错误发生，并且完全是由于环境的问题导致。而如果你在J2EE的环境下工作，并且得到NoClassDefFoundError的异常，而且对应的错误的类是确实存在的，这说明这个类对于类加载器来说，可能是不可见的。

怎么解决NoClassDefFoundError错误

根据前文，很明显NoClassDefFoundError的错误是因为在运行时类加载器在classpath下找不到需要加载的类，所以我们需要把对应的类加载到classpath中，或者检查为什么类在classpath中是不可用的，这个发生可能的原因如下：

对应的Class在java的classpath中不可用
你可能用jar命令运行你的程序，但类并没有在jar文件的manifest文件中的classpath属性中定义
可能程序的启动脚本覆盖了原来的classpath环境变量
因为NoClassDefFoundError是java.lang.LinkageError的一个子类，所以可能由于程序依赖的原生的类库不可用而导致
检查日志文件中是否有java.lang.ExceptionInInitializerError这样的错误，NoClassDefFoundError有可能是由于静态初始化失败导致的
如果你工作在J2EE的环境，有多个不同的类加载器，也可能导致NoClassDefFoundError
下面我们看一些当发生NoClassDefFoundError时，我们该如何解决的样例。

NoClassDefFoundError解决示例

当发生由于缺少jar文件，或者jar文件没有添加到classpath，或者jar的文件名发生变更会导致java.lang.NoClassDefFoundError的错误。
当类不在classpath中时，这种情况很难确切的知道，但如果在程序中打印出System.getproperty(“java.classpath”)，可以得到程序实际运行的classpath
运行时明确指定你认为程序能正常运行的 -classpath 参数，如果增加之后程序能正常运行，说明原来程序的classpath被其他人覆盖了。
NoClassDefFoundError也可能由于类的静态初始化模块错误导致，当你的类执行一些静态初始化模块操作，如果初始化模块抛出异常，哪些依赖这个类的其他类会抛出NoClassDefFoundError的错误。如果你查看程序日志，会发现一些java.lang.ExceptionInInitializerError的错误日志，ExceptionInInitializerError的错误会导致java.lang.NoClassDefFoundError: Could not initialize class，如下面的代码示例：
/**
* Java program to demonstrate how failure of static initialization subsequently cause
* java.lang.NoClassDefFoundError in Java.
* @author Javin Paul
*/
public class {

public static void main(String args[]){

List<User> users = new ArrayList<User>(2);

for(int i=0; i<2; i++){
try{
users.add(new User(String.valueOf(i))); //will throw NoClassDefFoundError
}catch(Throwable t){
t.printStackTrace();
}
}
}
}

class User{
private static String USER_ID = getUserId();

public User(String id){
this.USER_ID = id;
}
private static String getUserId() {
throw new RuntimeException("UserId Not found");
}
}

Output
java.lang.ExceptionInInitializerError
at testing..main(.java:23)
Caused by: java.lang.RuntimeException: UserId Not found
at testing.User.getUserId(.java:41)
at testing.User.<clinit>(.java:35)
... 1 more
java.lang.NoClassDefFoundError: Could not initialize class testing.User
at testing..main(.java:23)

Read more: http://javarevisited.blogspot.com/2011/06/noclassdeffounderror-exception-in.html#ixzz3dqtbvHDy

由于NoClassDefFoundError是LinkageError的子类，而LinkageError的错误在依赖其他的类时会发生，所以如果你的程序依赖原生的类库和需要的dll不存在时，有可能出现java.lang.NoClassDefFoundError。这种错误也可能抛出java.lang.UnsatisfiedLinkError: no dll in java.library.path Exception Java这样的异常。解决的办法是把依赖的类库和dll跟你的jar包放在一起。
如果你使用Ant构建脚本来生成jar文件和manifest文件，要确保Ant脚本获取的是正确的classpath值写入到manifest.mf文件
Jar文件的权限问题也可能导致NoClassDefFoundError，如果你的程序运行在像linux这样多用户的操作系统种，你需要把你应用相关的资源文件，如Jar文件，类库文件，配置文件的权限单独分配给程序所属用户组，如果你使用了多个用户不同程序共享的jar包时，很容易出现权限问题。比如其他用户应用所属权限的jar包你的程序没有权限访问，会导致java.lang.NoClassDefFoundError的错误。
基于XML配置的程序也可能导致NoClassDefFoundError的错误。比如大多数Java的框架像Spring，Struts使用xml配置获取对应的bean信息，如果你输入了错误的名称，程序可能会加载其他错误的类而导致NoClassDefFoundError异常。我们在使用Spring MVC框架或者Apache Struts框架，在部署War文件或者EAR文件时就经常会出现Exception in thread “main” java.lang.NoClassDefFoundError。
在有多个ClassLoader的J2EE的环境中，很容易出现NoClassDefFoundError的错误。由于J2EE没有指明标准的类加载器，使用的类加载器依赖与不同的容器像Tomcat、WebLogic，WebSphere加载J2EE的不同组件如War包或者EJB-JAR包。关于类加载器的相关知识可以参考这篇文章类加载器的工作原理。

总结来说，类加载器基于三个机制：委托、可见性和单一性，委托机制是指将加载一个类的请求交给父类加载器，如果这个父类加载器不能够找到或者加载这个类，那么再加载它。可见性的原理是子类的加载器可以看见所有的父类加载器加载的类，而父类加载器看不到子类加载器加载的类。单一性原理是指仅加载一个类一次，这是由委托机制确保子类加载器不会再次加载父类加载器加载过的类。现在假设一个User类在WAR文件和EJB-JAR文件都存在，并且被WAR ClassLoader加载，而WAR ClassLoader是加载EJB-JAR ClassLoader的子ClassLoader。当EJB-JAR中代码引用这个User类时，加载EJB-JAR所有class的Classloader找不到这个类，因为这个类已经被EJB-JAR classloader的子加载器WAR classloader加载。

这会导致的结果就是对User类出现NoClassDefFoundError异常，而如果在两个JAR包中这个User类都存在，如果你使用equals方法比较两个类的对象时，会出现ClassCastException的异常，因为两个不同类加载器加载的类无法进行比较。

有时候会出现Exception in thread “main” java.lang.NoClassDefFoundError: com/sun/tools/javac/Main 这样的错误，这个错误说明你的Classpath, PATH 或者 JAVA_HOME没有安装配置正确或者JDK的安装不正确。这个问题的解决办法时重新安装你的JDK。

Java在执行linking操作的时候，也可能导致NoClassDefFoundError。例如在前面的脚本中，如果在编译完成之后，我们删除User的编译文件，再运行程序，这个时候你就会直接得到NoClassDefFoundError，而错误的消息只打印出User类的名称。
java.lang.NoClassDefFoundError: testing/User
at testing..main(.java:23)

现在我们知道要怎样去面对NoClassDefFoundError异常并解决它了。

J. 在c语言中“可执行程序”是什么意思

C语言中的可执行程序就是将用文本信息表示的程序翻译成计算机认识的二进制代码串。

首先，我们先用C语言把源代码写好，然后交给C语言编译器。C语言编译器内部分为前端和后端。

（1）编译器前端

前端负责将C语言代码进行词法和语法上的解析，然后可以生成中间代码。

中间代码这部分不是必须的，但是它能够为程序的跨平台移植带来诸多好处。比如，同样的一份C语言源代码在一台计算机上编译完之后，生成一套中间代码。

然后针对不同的目标平台（比如要将这一套代码分别编译成 ARM 处理器的二进制机器码、MIPS 处理器的二进制机器码以及 x86 处理器的二进制机器码），只需要编写相应目标平台的编译器后端即可。

所以，这么做就可以把编译器的前端与后端剥离开来（这在软件工程上又可称为解耦合），不同处理器厂商可以针对自家的处理器特性，对中间代码生成到目标二进制代码的过程再度进行优化。

（2）编译器后端

接下来，由C语言编译器后端生成源文件相应的目标文件。

目标文件在 Windows 系统上往往是.obj文件，而在 Unix/Linux 系统上往往是.o文件，C语言的源文件在所有平台上都统一用.c文件表示。

（3）链接器

最后，对于各个独立的目标文件，通过连接器将它们合并成一个最终可执行文件。

(10)对象被多个用户共用仍要编译吗扩展阅读:

起初，C语言没有官方标准。1978年由美国电话电报公司(AT&T）贝尔实验室正式发表了C语言。布莱恩·柯林汉（Brian Kernighan） 和 丹尼斯·里奇（Dennis Ritchie） 出版了一本书，名叫《The C Programming Language》。

这本书被 C语言开发者们称为K&R，很多年来被当作 C语言的非正式的标准说明。人们称这个版本的 C语言为K&R C。

K&R C主要介绍了以下特色：

结构体（struct）类型

长整数（long int）类型

无符号整数（unsigned int）类型

把运算符=+和=-改为+=和-=。因为=+和=-会使得编译器不知道使用者要处理i = -10还是i =- 10，使得处理上产生混淆。

即使在后来ANSI C标准被提出的许多年后，K&R C仍然是许多编译器的最 准要求，许多老旧的编译器仍然运行K&R C的标准。

1970到80年代，C语言被广泛应用，从大型主机到小型微机，也衍生了C语言的很多不同版本。

1983年，美国国家标准协会（ANSI）成立了一个委员会X3J11，来制定 C语言标准。

1989年，美国国家标准协会（ANSI）通过了C语言标准，被称为ANSI X3.159-1989 "Programming Language C"。因为这个标准是1989年通过的，所以一般简称C89标准。有些人也简称ANSI C，因为这个标准是美国国家标准协会（ANSI）发布的。

1990年，国际标准化组织（ISO）和国际电工委员会（IEC）把C89标准定为C语言的国际标准，命名为ISO/IEC 9899:1990 - Programming languages -- C 。因为此标准是在1990年发布的，所以有些人把简称作C90标准。不过大多数人依然称之为C89标准，因为此标准与ANSI C89标准完全等同。

1994年，国际标准化组织（ISO）和国际电工委员会（IEC）发布了C89标准修订版，名叫ISO/IEC 9899:1990/Cor 1:1994 ，有些人简称为C94标准。

1995年，国际标准化组织（ISO）和国际电工委员会（IEC）再次发布了C89标准修订版，名叫ISO/IEC 9899:1990/Amd 1:1995 - C Integrity ，有些人简称为C95标准。

C99标准

1999年1月，国际标准化组织（ISO）和国际电工委员会（IEC）发布了C语言的新标准，名叫ISO/IEC 9899:1999 - Programming languages -- C ，简称C99标准。这是C语言的第二个官方标准。

参考资料:网络-c语言