Java语言定义了public、protected、private、abstract、static和final这6常用修饰
词外还定义了5个不太常用的修饰词，下面是对这11个Java修饰词的介绍：
1.public
使用对象：类、接口、成员
介绍：无论它所处在的包定义在哪，该类（接口、成员）都是可访问的
2.private
使用对象：成员
介绍：成员只可以在定义它的类中被访问
3.static
使用对象：类、方法、字段、初始化函数
介绍：成名为static的内部类是一个顶级类，它和包含类的成员是不相关的。静态方法
是类方法，
是被指向到所属的类而不是类的实例。静态字段是类字段，无论该字段所在的类创建了
多少实例，该字
段只存在一个实例被指向到所属的类而不是类的实例。初始化函数是在装载类时执行
的，而不是在创建
实例时执行的。
4.final
使用对象：类、方法、字段、变量
介绍：被定义成final的类不允许出现子类，不能被覆盖（不应用于动态查询），字段值
不允许被
修改。
5.abstract
使用对象：类、接口、方法
介绍：类中包括没有实现的方法，不能被实例化。如果是一个abstract方法，则方法体
为空，该方
法的实现在子类中被定义，并且包含一个abstract方法的类必须是一个abstract类
6.protected
使用对象：成员
介绍：成员只能在定义它的包中被访问，如果在其他包中被访问，则实现这个方法的类
必须是该成
员所属类的子类。
7.native
使用对象：成员
介绍：与操作平台相关，定义时并不定义其方法，方法的实现被一个外部的库实现。
8.strictfp
使用对象：类、方法
介绍：strictfp修饰的类中所有的方法都隐藏了strictfp修饰词，方法执行的所有浮点
计算遵守
IEEE 754标准，所有取值包括中间的结果都必须表示为float或double类型，而不能利用
由本地平台浮
点格式或硬件提供的额外精度或表示范围。
9.synchronized
使用对象：方法
介绍：对于一个静态的方法，在执行之前jvm把它所在的类锁定；对于一个非静态类的方
法，执行
前把某个特定对象实例锁定。
10.volatile
使用对象：字段
介绍：因为异步线程可以访问字段，所以有些优化操作是一定不能作用在字段上的。
volatile修饰变量。在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。而且，当成员变量发生变化时，强迫线程将变化值回写到共享内存。这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。
看看Java Language Specification中的例子。
条件：一个线程不停的调用方法one()，一个线程不停的调用方法two()。我测试过多次，这种情况好像一直没有出现。
代码
class Test {
static int i = 0, j = 0;
static void one() { i++; j++; }
static void two() {
System.out.println("i=" + i + " j=" + j);
}
}
结果偶尔会出现j大于i的情况，因为方法没有同步，所以会出现i和j可能不是一次更新。一种防止这种情况发生的办法就是声明两个方法为synchronized 的。
代码
class Test {
static int i = 0, j = 0;
static synchronized void one() { i++; j++; }
static synchronized void two() {
System.out.println("i=" + i + " j=" + j);
}
}
这样可以防止两个方法同时被执行，还可以保证j和i被同时更新，这样一来i和j的值一直是一样的。
另外一种途径就是把i和j声明为volatile。
代码
class Test {
static volatile int i = 0, j = 0;
static void one() { i++; j++; }
static void two() {
System.out.println("i=" + i + " j=" + j);
}
}
volatile有时
可以代替synchronized。
11.transient
使用对象：字段
介绍：字段不是对象持久状态的一部分，不应该把字段和对象一起串起。
transient是一个变量修饰符,标记为transient的变量，在对一个对象进行序列化时，这些变量状态不会被序列化。
例如，假设某个类的成员变量是transient，那么当通过ObjectOutputStream把这个类的某个实例保存到磁盘上时，实际上transient变量的值是不会保存的。
当对象序列化的保存在存储器上时，不希望有些字段数据被保存，为了保证安全性，可以把这些字段声明为transient。
要更明白，可以看一些序列化的内容。
-------------------------------------------------------
[关键字] JavaClassLoader Package
为了深入了解Java的ClassLoader机制，我们先来做以下实验：
package java.lang;
public class Test {
public static void main(String[] args) {
char[] c = "1234567890".toCharArray();
String s = new String(0, 10, c);
}
}
String类有一个Package权限的构造函数String(int offset, int length, char[] array)，按照默认的访问权限，由于Test属于java.lang包，因此理论上应该可以访问String的这个构造函数。编译通过！执行时结果如下：
Exception in thread "main" java.lang.SecurityException: Prohibited package name:
java.lang
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
奇怪吧？要弄清为什么会有SecurityException，就必须搞清楚ClassLoader的机制。
Java的ClassLoader就是用来动态装载class的，ClassLoader对一个class只会装载一次，JVM使用的ClassLoader一共有4种：
启动类装载器，标准扩展类装载器，类路径装载器和网络类装载器。
这4种ClassLoader的优先级依次从高到低，使用所谓的“双亲委派模型”。确切地说，如果一个网络类装载器被请求装载一个java.lang.Integer，它会首先把请求发送给上一级的类路径装载器，如果返回已装载，则网络类装载器将不会装载这个java.lang.Integer，如果上一级的类路径装载器返回未装载，它才会装载java.lang.Integer。
类似的，类路径装载器收到请求后（无论是直接请求装载还是下一级的ClassLoader上传的请求），它也会先把请求发送到上一级的标准扩展类装载器，这样一层一层上传，于是启动类装载器优先级最高，如果它按照自己的方式找到了java.lang.Integer，则下面的ClassLoader 都不能再装载java.lang.Integer，尽管你自己写了一个java.lang.Integer，试图取代核心库的java.lang.Integer是不可能的，因为自己写的这个类根本无法被下层的ClassLoader装载。
再说说Package权限。Java语言规定，在同一个包中的class，如果没有修饰符，默认为Package权限，包内的class都可以访问。但是这还不够准确。确切的说，只有由同一个ClassLoader装载的class才具有以上的Package权限。比如启动类装载器装载了java.lang.String，类路径装载器装载了我们自己写的java.lang.Test，它们不能互相访问对方具有Package权限的方法。这样就阻止了恶意代码访问核心类的Package权限方法
ava不是完美的，Java的不足除了体现在运行速度上要比传统的C++慢许多之外，Java无法直接访问到操作系统底层（如系统硬件等)，为此Java使用native方法来扩展Java程序的功能。
可以将native方法比作Java程序同Ｃ程序的接口，其实现步骤：
１、在Java中声明native()方法，然后编译；
２、用javah产生一个.h文件；
３、写一个.cpp文件实现native导出方法，其中需要包含第二步产生的.h文件（注意其中又包含了JDK带的jni.h文件）；
４、将第三步的.cpp文件编译成动态链接库文件；
５、在Java中用System.loadLibrary()方法加载第四步产生的动态链接库文件，这个native()方法就可以在Java中被访问了。
JAVA本地方法适用的情况
1.为了使用底层的主机平台的某个特性，而这个特性不能通过JAVA API访问
2.为了访问一个老的系统或者使用一个已有的库，而这个系统或这个库不是用JAVA编写的
3.为了加快程序的性能，而将一段时间敏感的代码作为本地方法实现。
首先写好JAVA文件
package com.hode.hodework.modelupdate;
public class CheckFile
{
public native void displayHelloWorld();
static
{
System.loadLibrary("test");
}
public static void main(String[] args) {
new CheckFile().displayHelloWorld();
}
}
然后根据写好的文件编译成CLASS文件
然后在classes或bin之类的class根目录下执行javah -jni com.hode.hodework.modelupdate.CheckFile，
就会在根目录下得到一个com_hode_hodework_modelupdate_CheckFile.h的文件
然后根据头文件的内容编写com_hode_hodework_modelupdate_CheckFile.c文件
＃i nclude "CheckFile.h"
＃i nclude
＃i nclude
JNIEXPORT void JNICALL Java_com_hode_hodework_modelupdate_CheckFile_displayHelloWorld(JNIEnv *env, jobject obj)
{
printf("Hello world!\n");
return;
}
之后编译生成DLL文件如“test.dll”，名称与System.loadLibrary("test")中的名称一致
vc的编译方法：cl -I%java_home%\include -I%java_home%\include\win32 -LD com_hode_hodework_modelupdate_CheckFile.c -Fetest.dll
最后在运行时加参数-Djava.library.path=[dll存放的路径]
一. 什么是Native Method
简单地讲，一个Native Method就是一个java调用非java代码的接口。一个Native Method是这样一个java的方法：该方法的实现由非java语言实现，比如C。这个特征并非java所特有，很多其它的编程语言都有这一机制，比如在C＋＋中，你可以用extern "C"告知C＋＋编译器去调用一个C的函数。
"A native method is a Java method whose implementation is provided by non-java code."
在定义一个native method时，并不提供实现体（有些像定义一个java interface），因为其实现体是由非java语言在外面实现的。，下面给了一个示例：
public class IHaveNatives
{
native public void Native1( int x ) ;
native static public long Native2() ;
native synchronized private float Native3( Object o ) ;
native void Native4( int[] ary ) throws Exception ;
}
这些方法的声明描述了一些非java代码在这些java代码里看起来像什么样子（view）.
标识符native可以与所有其它的java标识符连用，但是abstract除外。这是合理的，因为native暗示这些方法是有实现体的，只不过这些实现体是非java的，但是abstract却显然的指明这些方法无实现体。native与其它java标识符连用时，其意义同非Native Method并无差别，比如native static表明这个方法可以在不产生类的实例时直接调用，这非常方便，比如当你想用一个native method去调用一个C的类库时。上面的第三个方法用到了native synchronized，JVM在进入这个方法的实现体之前会执行同步锁机制（就像java的多线程。）
一个native method方法可以返回任何java类型，包括非基本类型，而且同样可以进行异常控制。这些方法的实现体可以制一个异常并且将其抛出，这一点与java的方法非常相似。当一个native method接收到一些非基本类型时如Object或一个整型数组时，这个方法可以访问这非些基本型的内部，但是这将使这个native方法依赖于你所访问的java类的实现。有一点要牢牢记住：我们可以在一个native method的本地实现中访问所有的java特性，但是这要依赖于你所访问的java特性的实现，而且这样做远远不如在java语言中使用那些特性方便和容易。
native method的存在并不会对其他类调用这些本地方法产生任何影响，实际上调用这些方法的其他类甚至不知道它所调用的是一个本地方法。JVM将控制调用本地方法的所有细节。需要注意当我们将一个本地方法声明为final的情况。用java实现的方法体在被编译时可能会因为内联而产生效率上的提升。但是一个native final方法是否也能获得这样的好处却是值得怀疑的，但是这只是一个代码优化方面的问题，对功能实现没有影响。
如果一个含有本地方法的类被继承，子类会继承这个本地方法并且可以用java语言重写这个方法（这个似乎看起来有些奇怪），同样的如果一个本地方法被fianl标识，它被继承后不能被重写。
本地方法非常有用，因为它有效地扩充了jvm.事实上，我们所写的java代码已经用到了本地方法，在sun的java的并发（多线程）的机制实现中，许多与操作系统的接触点都用到了本地方法，这使得java程序能够超越java运行时的界限。有了本地方法，java程序可以做任何应用层次的任务。
二.为什么要使用Native Method
java使用起来非常方便，然而有些层次的任务用java实现起来不容易，或者我们对程序的效率很在意时，问题就来了。
与java环境外交互：
有时java应用需要与java外面的环境交互。这是本地方法存在的主要原因，你可以想想java需要与一些底层系统如操作系统或某些硬件交换信息时的情况。本地方法正是这样一种交流机制：它为我们提供了一个非常简洁的接口，而且我们无需去了解java应用之外的繁琐的细节。
与操作系统交互：
JVM支持着java语言本身和运行时库，它是java程序赖以生存的平台，它由一个解释器（解释字节码）和一些连接到本地代码的库组成。然而不管怎样，它毕竟不是一个完整的系统，它经常依赖于一些底层（underneath在下面的）系统的支持。这些底层系统常常是强大的操作系统。通过使用本地方法，我们得以用java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用C写的，还有，如果我们要使用一些java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法。
Sun's Java
Sun的解释器是用C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分是用java实现的，它也通过一些本地方法与外界交互。例如：类 java.lang.Thread 的 setPriority()方法是用java实现的，但是它实现调用的是该类里的本地方法setPriority0()。这个本地方法是用C实现的，并被植入JVM内部，在Windows 95的平台上，这个本地方法最终将调用Win32 SetPriority() API。这是一个本地方法的具体实现由JVM直接提供，更多的情况是本地方法由外部的动态链接库（external dynamic link library）提供，然后被JVM调用。
三.JVM怎样使Native Method跑起来：
我们知道，当一个类第一次被使用到时，这个类的字节码会被加载到内存，并且只会回载一次。在这个被加载的字节码的入口维持着一个该类所有方法描述符的 list，这些方法描述符包含这样一些信息：方法代码存于何处，它有哪些参数，方法的描述符（public之类）等等。
如果一个方法描述符内有native，这个描述符块将有一个指向该方法的实现的指针。这些实现在一些DLL文件内，但是它们会被操作系统加载到java程序的地址空间。当一个带有本地方法的类被加载时，其相关的DLL并未被加载，因此指向方法实现的指针并不会被设置。当本地方法被调用之前，这些DLL才会被加载，这是通过调用 java.system.loadLibrary()实现的。
最后需要提示的是，使用本地方法是有开销的，它丧失了java的很多好处。如果别无选择，我们可以选择使用本地方法。
来源：https://www.cnblogs.com/beanmoon/archive/2012/04/26/2472031.html