「java同步屏障」java 同步屏障

今天给各位分享java同步屏障的知识，其中也会对java 同步屏障进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、关于 Handler 的这 20 个问题，你都清楚吗？
• 2、如何解决Java线程同步中的阻塞问题
• 3、为什么这样写Java线程的屏障类（Barrier）不行？
• 4、Java语言的特点
• 5、华为服务器32根内存插法
• 6、内存屏障

关于 Handler 的这 20 个问题，你都清楚吗？

Android 11 开始，AsyncTask 正式谢幕，变成了不推荐使用的 API。官方建议采用 Kotlin 协程替代，或者自行实现。

事实上，无论是 AsyncTask 还是协程，背后都有 Handler 的功劳。无论从普及原理的角度、还是从自行实现的角度，我们都需要吃透这个 Android 系统所特有的线程间通信方式Handler 机制！

初尝 Handler 机制的时候，原以为 Handler 类发挥了很大的作用。当你深入了解它的原理之后，会发现 Handler 只是该机制的 调用入口和回调 而已，最重要的东西是 Looper 和 MessagQueue，以及不断流转的 Message。

本次针对 Handler 机制常被提及和容易困扰的  20  个问题进行整理和回答，供大家解惑和回顾~

简述下 Handler 机制的总体原理？

Looper 存在哪？如何可以保证线程独有？

如何理解 ThreadLocal 的作用？

主线程 Main Looper 和一般 Looper 的异同？

Handler 或者说 Looper 如何切换线程？

Looper 的 loop() 死循环为什么不卡死？

Looper 的等待是如何能够准确唤醒的？

Message 如何获取？为什么这么设计？

MessageQueue 如何管理 Message？

理解 Message 和 MessageQueue 的异同？

Message 的执行时刻如何管理？

Handler、Mesage 和 Runnable 的关系如何理解？

IdleHandler 空闲 Message 了解过吗？有什么用？

异步 Message 或同步屏障了解过吗？怎么用？什么原理？

Looper 和 MessageQueue、Message 及 Handler 的关系？

Native 侧的 NativeMessageQueue 和 Looper 的作用是？

Native 侧如何使用 Looper？

Handler 为什么可能导致内存泄露？如何避免？

Handler 在系统当中的应用

Android 为什么不允许并发访问 UI？

1. 简述下 Handler 机制的总体原理？

Looper 准备和开启轮循：

尚无 Message 的话，调用 Native 侧的 pollOnce() 进入 无限等待

存在 Message，但执行时间 when 尚未满足的话，调用 pollOnce() 时传入剩余时长参数进入 有限等待

Looper#prepare() 初始化线程独有的 Looper 以及 MessageQueue

Looper#loop() 开启 死循环 读取 MessageQueue 中下一个满足执行时间的 Message

Message 发送、入队和出队：

Native 侧如果处于无限等待的话：任意线程向 Handler 发送 Message 或 Runnable 后，Message 将按照 when 条件的先后，被插入 Handler 持有的 Looper 实例所对应的 MessageQueue  中 适当的位置 。MessageQueue 发现有合适的 Message 插入后将调用 Native 侧的 wake() 唤醒无限等待的线程。这将促使 MessageQueue 的读取继续 进入下一次循环 ，此刻 Queue 中已有满足条件的 Message 则出队返回给 Looper

Native 侧如果处于有限等待的话：在等待指定时长后 epoll_wait 将返回。线程继续读取 MessageQueue，此刻因为时长条件将满足将其出队

Looper 处理 Message 的实现：

Looper 得到 Message 后回调 Message 的 callback 属性即 Runnable，或依据 target 属性即 Handler，去执行 Handler 的回调。

存在 mCallback 属性的话回调 Handler$Callback

反之，回调 handleMessage()

2. Looper 存在哪？如何可以保证线程独有？

Looper 实例被管理在静态属性 sThreadLocal 中

ThreadLocal 内部通过 ThreadLocalMap 持有 Looper，key 为 ThreadLocal 实例本身，value 即为 Looper 实例

每个 Thread 都有一个自己的 ThreadLocalMap，这样可以保证每个线程对应一个独立的 Looper 实例，进而保证 myLooper() 可以获得线程独有的 Looper

彩蛋：一个 App 拥有几个 Looper 实例？几个 ThreadLocal 实例？几个 MessageQueue 实例？几个 Message 实例？几个 Handler 实例

一个线程只有一个 Looper 实例

一个 Looper 实例只对应着一个 MessageQueue 实例

一个 MessageQueue 实例可对应多个 Message 实例，其从 Message 静态池里获取，存在 50 的上限

一个线程可以拥有多个 Handler 实例，其Handler 只是发送和执行任务逻辑的入口和出口

ThreadLocal 实例是静态的，整个进程 共用一个实例 。每个 Looper 存放的 ThreadLocalMap 均弱引用它作为 key

3. 如何理解 ThreadLocal 的作用？

首先要明确并非不是用来切换线程的， 只是为了让每个线程方便程获取自己的 Looper 实例 ，见 Looper#myLooper()

后续可供 Handler 初始化时 指定其所属的 Looper 线程

也可用来线程判断自己是否 是主线程

4. 主线程 Main Looper 和一般 Looper 的异同？

区别：

Main Looper  不可 quit

主线程需要不断读取系统消息和用书输入，是进程的入口，只可被系统直接终止。进而其 Looper 在创建的时候设置了 不可quit的标志 ，而 其他线程的 Looper 则可以也必须手动 quit

Main Looper 实例还被 静态缓存

为了便于每个线程获得主线程 Looper 实例，见 Looper#getMainLooper()，Main Looper 实例还作为 sMainLooper 属性缓存到了 Looper 类中。

相同点：

都是通过 Looper#prepare() 间接调用 Looper 构造函数创建的实例

都被静态实例 ThreadLocal 管理，方便每个线程获取自己的 Looper 实例

彩蛋：主线程为什么不用初始化 Looper？

App 的入口并非 MainActivity，也不是 Application，而是 ActivityThread。

其为了 Application、ContentProvider、Activity 等组件的运行，必须事先启动不停接受输入的 Looper 机制，所以在 main() 执行的最后将调用 prepareMainLooper() 创建 Looper 并调用 loop() 轮循。

不需要我们调用，也不可能有我们调用。

可以说如果主线程没有创建 Looper 的话，我们的组件也不可能运行得到！

5. Handler 或者说 Looper 如何切换线程？

Handler 创建的时候指定了其所属线程的 Looper，进而持有了 Looper 独有的 MessageQueue

Looper#loop() 会持续读取 MessageQueue 中合适的 Message，没有 Message 的时候进入等待

当向 Handler 发送 Message 或 Runnable 后，会向持有的 MessageQueue 中插入 Message

Message 抵达并满足条件后会唤醒 MessageQueue 所属的线程，并将 Message 返回给 Looper

Looper 接着回调 Message 所指向的 Handler Callback 或 Runnable，达到线程切换的目的

简言之，向 Handler 发送 Message 其实是向 Handler 所属线程的独有 MessageQueue 插入 Message。而线程独有的 Looper 又会持续读取该 MessageQueue。所以向其他线程的 Handler 发送完 Message，该线程的 Looper 将自动响应。

6. Looper 的 loop() 死循环为什么不卡死？

为了让主线程持续处理用户的输入，loop() 是 死循环 ，持续调用 MessageQueue#next() 读取合适的 Message。

但当没有 Message 的时候，会调用 pollOnce() 并通过 Linux 的 epoll 机制进入等待并释放资源。同时 eventFd 会监听 Message 抵达的写入事件并进行唤醒。

这样可以 空闲时释放资源、不卡死线程，同时能持续接收输入的目的 。

彩蛋1：loop() 后的处理为什么不可执行

因为 loop() 是死循环，直到 quit 前后面的处理无法得到执行，所以避免将处理放在 loop() 的后面。

彩蛋2：Looper 等待的时候线程到底是什么状态？

调用 Linux 的 epoll 机制进入 等待 ，事实上 Java 侧打印该线程的状态，你会发现线程处于 Runnable 状态，只不过 CPU 资源被暂时释放。

7. Looper 的等待是如何能够准确唤醒的？

读取合适 Message 的 MessageQueue#next() 会因为 Message 尚无或执行条件尚未满足进行两种等的等待：

无限等待

尚无 Message（队列中没有 Message 或建立了同步屏障但尚无异步 Message）的时候，调用 Natvie 侧的 pollOnce() 会传入参数  -1 。

Linux 执行 epoll_wait() 将进入无限等待，其等待合适的 Message 插入后调用 Native 侧的 wake() 向唤醒 fd 写入事件触发唤醒 MessageQueue 读取的下一次循环

有限等待

有限等待的场合将下一个 Message  剩余时长作为参数 交给 epoll_wait()，epoll 将等待一段时间之后 自动返回 ，接着回到 MessageQueue 读取的下一次循环

8. Message 如何获取？为什么这么设计？

享元设计模式：通过 Message 的静态方法 obatin() 获取，因为该方法不是无脑地 new，而是 从单链表池子里获取实例 ，并在 recycle() 后将其放回池子

好处在于复用 Message 实例，满足频繁使用 Message 的场景，更加高效

当然，缓存池存在上限  50 ，因为没必要无限制地缓存，这本身也是一种浪费

需要留意缓存池是静态的，也就是整个进程共用一个缓存池

9. MessageQueue 如何管理 Message？

MessageQueue 通过单链表管理 Message，不同于进程共用的 Message Pool，其是线程独有的

通过 Message 的执行时刻 when 对 Message 进行排队和出队

MessageQueue 除了管理 Message，还要管理空闲 Handler 和 同步屏障

10. 理解 Message 和 MessageQueue 的异同？

相同点：都是通过 单链表来管理  Message 实例；

Message 通过  obtain() 和 recycle()  向单链表获取插入节点

MessageQueue 通过  enqueueMessage() 和 next()  向单链表获取和插入节点

区别：

Message 单链表是 静态的，供进程使用的缓存池

MessageQueue 单链表 非静态，只供 Looper 线程使用

11. Message 的执行时刻如何管理？

发送的 Message 都是按照执行时刻 when 属性的先后管理在 MessageQueue 里

延时 Message 的 when 等于调用的当前时刻和 delay 之和

非延时 Message 的 when 等于当前时刻（delay 为 0）

插队 Message 的 when 固定为 0，便于插入队列的 head

之后 MessageQueue 会根据 读取的时刻和 when 进行比较

将 when 已抵达的出队，

尚未抵达的计算出 当前时刻和目标 when 的插值 ，交由 Native 等待对应的时长，时间到了自动唤醒继续进行 Message 的读取

事实上，无论上述哪种 Message 都不能保证在其对应的 when 时刻执行，往往都会延迟一些！因为必须等当前执行的 Message 处理完了才有机会读取队列的下一个 Message。

比如发送了非延时 Message，when 即为发送的时刻，可它们不会立即执行。都要等主线程现有的任务（Message）走完才能有机会出队，而当这些任务执行完 when 的时刻已经过了。假使队列的前面还有其他 Message 的话，延迟会更加明显！

彩蛋：. onCreate() 里向 Handler 发送大量 Message 会导致主线程卡顿吗？

不会，发送的大量 Message 并非立即执行，只是先放到队列当中而已。

onCreate() 以及之后同步调用的 onStart() 和 onResume() 处理，本质上也是 Message。等这个 Message 执行完之后，才会进行读取 Message 的下一次循环，这时候才能回调 onCreate 里发送的 Message。

需要说明的是，如果发送的是 FrontOfQueue 将 Message 插入队首也不会立即先执行，因为 onStart 和 onResume 是 onCreate 之后同步调用的，本质上是同一个 Message 的作业周期

12. Handler、Mesage 和 Runnable 的关系如何理解？

作为使用 Handler 机制的入口， Handler 是发送 Message 或 Runnable 的起点

发送的  Runnable 本质上也是 Message ，只不过作为 callback 属性被持有

Handler 作为 target 属性被持有在 Mesage 中 ，在 Message 执行条件满足的时候供 Looper 回调

事实上，Handler 只是供 App 使用 Handler 机制的 API，实质来说，Message 是更为重要的载体。

13. IdleHandler 空闲 Message 了解过吗？有什么用？

适用于期望 空闲时候执行，但不影响主线程操作 的任务

系统应用：

Activity destroy 回调就放在了 IdleHandler 中

ActivityThread 中 GCHandler 使用了 IdleHandler，在空闲的时候执行  GC  操作

App 应用：

发送一个返回 true 的 IdleHandler，在里面让某个 View 不停闪烁，这样当用户发呆时就可以诱导用户点击这个 View

将某部分初始化放在 IdleHandler 里不影响 Activity 的启动

14. 异步 Message 或同步屏障了解过吗？怎么用？什么原理？

异步 Message：设置了 isAsync 属性的 Message 实例

可以用异步 Handler 发送

也可以调用 Message#setAsynchronous() 直接设置为异步 Message

同步屏障：在 MessageQueue 的 某个位置放一个 target 属性为 null 的 Message ，确保此后的非异步 Message 无法执行，只能执行异步 Message

原理：当 MessageQueue 轮循 Message 时候 发现建立了同步屏障的时候，会去跳过其他 Message，读取下个 async 的 Message 并执行，屏障移除之前同步 Message 都会被阻塞

应用：比如 屏幕刷新 Choreographer 就使用到了同步屏障 ，确保屏幕刷新事件不会因为队列负荷影响屏幕及时刷新。

注意： 同步屏障的添加或移除 API 并未对外公开，App 需要使用的话需要依赖反射机制

15. Looper 和 MessageQueue、Message 及 Handler 的关系？

Message 是承载任务的载体，在 Handler 机制中贯穿始终

Handler 则是对外公开的 API，负责发送 Message 和处理任务的回调，是  Message 的生产者

MessagQueue 负责管理待处理 Message 的入队和出队，是  Message 的容器

Looper 负责轮循 MessageQueue，保持线程持续运行任务，是  Message 的消费者

彩蛋：如何保证 MessageQueue 并发访问安全？

任何线程都可以通过 Handler 生产 Message 并放入 MessageQueue 中，可 Queue 所属的 Looper 在持续地读取并尝试消费 Message。如何保证两者不产生死锁？

Looper 在消费 Message 之前要先拿到 MessageQueue  的锁， 只不过没有 Message 或 Message 尚未满足条件的进行等待前会事先释放锁 ，具体在于 nativePollOnce() 的调用在 synchronized 方法块的外侧。

Message 入队前也需先拿到 MessageQueue  的锁，而这时 Looper 线程正在等待且不持有锁，可以确保 Message 的成功入队。入队后执行唤醒后释放锁，Native 收到 event 写入后恢复 MessagQueue 的读取并可以拿到锁，成功出队。

这样一种在没有 Message 可以消费时执行等待同时不占着锁的机制，避免了生产和消费的死锁。

16. Native 侧的 NativeMessageQueue 和 Looper 的作用是？

NativeMessageQueue 负责连接 Java 侧的 MessageQueue，进行后续的 wait 和 wake，后续将创建 wake 的FD，并通过 epoll 机制等待或唤醒。 但并不参与管理 Java 的 Message

Native 侧也需要 Looper 机制，等待和唤醒的需求是同样的，所以将这部分实现都封装到了 JNI 的NativeMessageQueue  和  Native 的 Looper 中， 供 Java 和 Native 一起使用

17. Native 侧如何使用 Looper？

Looper Native 部分承担了 Java 侧 Looper 的等待和唤醒，除此之外其还提供了 Message、MessageHandler 或 WeakMessageHandler、LooperCallback 或 SimpleLooperCallback 等 API

这些部分可供 Looper 被 Native 侧直接调用，比如 InputFlinger 广泛使用了 Looper

主要方法是调用 Looper 构造函数或 prepare 创建 Looper，然后通过 poll 开始轮询，接着 sendMessage 或 addEventFd，等待 Looper 的唤醒。 使用过程和 Java 的调用思路类似

18. Handler 为什么可能导致内存泄露？如何避免？

持有 Activity 实例的内名内部类或内部类的 生命周期 应当和 Activity 保持一致，否则产生内存泄露的风险。

如果 Handler 使用不当，将造成不一致，表现为：匿名内部类或内部类写法的 Handler、Handler$Callback、Runnable，或者Activity 结束时仍有活跃的 Thread 线程或 Looper 子线程

具体在于：异步任务仍然活跃或通过发送的 Message 尚未处理完毕，将使得内部类实例的 生命周期被错误地延长 。造成本该回收的 Activity 实例 被别的 Thread 或 Main Looper 占据而无法及时回收 （活跃的 Thread 或 静态属性 sMainLooper 是 GC Root 对象）

建议的做法：

无论是 Handler、Handler$Callback 还是 Runnable，尽量采用 静态内部类 + 弱引用 的写法，确保尽管发生不当引用的时候也可以因为弱引用能清楚持有关系

另外在 Activity 销毁的时候及时地 终止 Thread、停止子线程的 Looper 或清空 Message ，确保彻底切断 Activity 经由 Message 抵达 GC Root 的引用源头（Message 清空后会其与 Handler 的引用关系，Thread 的终止将结束其 GC Root 的源头）

注意：静态的 sThreadLocal 实例不持有存放 Looper 实例的 ThreadLocalMap，而是由 Thread 持有。从这个角度上来讲，Looper 会被活跃的 GC Root Thread 持有，进而也可能导致内存泄露。

彩蛋：网传的 Handler$Callback 方案能否解决内存泄露？

不能。

Callback 采用内部类或匿名内部类写法的话，默认持有 Activity 的引用，而 Callback 被 Handler 持有。这最终将导致 Message - Handler - Callback - Activity 的链条仍然存在。

19. Handler 在系统当中的应用

特别广泛，比如：

Activity 生命周期的管理

屏幕刷新

HandlerThread、IntentService

AsyncTask 等。

主要利用 Handler 的切换线程、主线程异步 Message 的重要特性。注意：Binder 线程非主线程，但很多操作比如生命周期的管理都要回到主线程，所以很多 Binder 调用过来后都要通过 Handler 切换回主线程执行后续任务，比如 ActviityThread$H 就是 extends Handler。

20. Android 为什么不允许并发访问 UI？

Android 中 UI 非线程安全，并发访问的话会造成数据和显示错乱。

但此限制的检查始于ViewRootImpl#checkThread()，其会在刷新等多个访问 UI 的时机被调用，去检查当前线程，非主线程的话抛出异常。

而 ViewRootImpl 的创建在 onResume() 之后，也就是说如果在 onResume() 执行前启动线程访问 UI 的话是不会报错的，这点需要留意！

彩蛋：onCreate() 里子线程更新 UI 有问题吗？为什么？

不会。

因为异常的检测处理在 ViewRootImpl 中，该实例的创建和检测在 onResume() 之后进行。

如何解决Java线程同步中的阻塞问题

Java线程同步需要我们不断的进行相关知识的学习，下面我们就来看看如何才能更好的在学习中掌握相关的知识讯息，来完善我们自身的编写手段。希望大家有所收获。 Java线程同步的优先级代表该线程的重要程度，当有多个线程同时处于可执行状态并等待获得 CPU 时间时，线程调度系统根据各个线程的优先级来决定给谁分配 CPU 时间，优先级高的线程有更大的机会获得 CPU 时间，优先级低的线程也不是没有机会，只是机会要小一些罢了。 你可以调用 Thread 类的方法 getPriority（）和 setPriority（）来存取Java线程同步的优先级，线程的优先级界于1（MIN_PRIORITY）和10（MAX_PRIORITY）之间，缺省是5（NORM_PRIORITY）。 Java线程同步 由于同一进程的多个线程共享同一片存储空间，在带来方便的同时，也带来了访问冲突这个严重的问题。Java语言提供了专门机制以解决这种冲突，有效避免了同一个数据对象被多个线程同时访问。 由于我们可以通过 private 关键字来保证数据对象只能被方法访问，所以我们只需针对方法提出一套机制，这套机制就是 synchronized 关键字，它包括两种用法：synchronized 方法和 synchronized 块。 1． synchronized 方法：通过在方法声明中加入 synchronized关键字来声明 synchronized 方法。如：1. public synchronized void accessVal（int newVal）； synchronized 方法控制对类成员变量的访问：每个类实例对应一把锁，每个 synchronized 方法都必须获得调用该方法的类实例的锁方能执行，否则所属线程阻塞，方法一旦执行，就独占该锁，直到从该方法返回时才将锁释放，此后被阻塞的Java线程同步方能获得该锁，重新进入可执行状态。 这种机制确保了同一时刻对于每一个类实例，其所有声明为 synchronized 的成员函数中至多只有一个处于可执行状态（因为至多只有一个能够获得该类实例对应的锁），从而有效避免了类成员变量的访问冲突（只要所有可能访问类成员变量的方法均被声明为 synchronized）。 在 Java 中，不光是类实例，每一个类也对应一把锁，这样我们也可将类的静态成员函数声明为 synchronized ，以控制其对类的静态成员变量的访问。 synchronized 方法的缺陷：若将一个大的方法声明为synchronized 将会大大影响效率，典型地，若将线程类的方法 run（）声明为 synchronized ，由于在线程的整个生命期内它一直在运行，因此将导致它对本类任何 synchronized 方法的调用都永远不会成功。当然我们可以通过将访问类成员变量的代码放到专门的方法中，将其声明为 synchronized ，并在主方法中调用来解决这一问题，但是 Java 为我们提供了更好的解决办法，那就是 synchronized 块。 2． synchronized 块：通过 synchronized关键字来声明synchronized 块。语法如下：1. synchronized（syncObject）2. {3. //允许访问控制的代码4. } synchronized 块是这样一个代码块，其中的代码必须获得对象 syncObject （如前所述，可以是类实例或类）的锁方能执行，具体机制同前所述。由于可以针对任意代码块，且可任意指定上锁的对象，故灵活性较高。 Java线程同步的阻塞 为了解决对共享存储区的访问冲突，Java 引入了同步机制，现在让我们来考察多个Java线程同步对共享资源的访问，显然同步机制已经不够了，因为在任意时刻所要求的资源不一定已经准备好了被访问，反过来，同一时刻准备好了的资源也可能不止一个。为了解决这种情况下的访问控制问题，Java 引入了对阻塞机制的支持。 阻塞指的是暂停一个Java线程同步的执行以等待某个条件发生（如某资源就绪），学过操作系统的同学对它一定已经很熟悉了。Java 提供了大量方法来支持阻塞，下面让我们逐一分析。

为什么这样写Java线程的屏障类（Barrier）不行？

代码的第三行使用了final关键字,在java中final的使用有以下几点 :

final是一个修饰符,可以用来修饰类,函数,变量;

final修饰的类不能被继承;

final修饰的函数不能被子类重写,但是可以被子类调用;

final修饰的变量为常量,声明时变量时,必须初始化,能且只能被赋值一次.

你的使用违反了第四条,你没有为cnt这个变量指明值,所以编译不能通过.

final声明的变量要初始化,有两种方式 :

声明时直接指明值,如 : final int cnt = 10 ;

声明时不初始化,但必须在构造器或者静态代码块中指明值,如下 :

a.

public class Barrier {

final int cnt;

public Barrier(){

cnt = 10 ;

}    

}

b.

public class Barrier {

static final int cnt;

static{

cnt = 10 ;

}

}

综上所述,建议修正后在进行测试.

如果有用请点赞!如果满意请采纳!您的支持就是我的最大动力!

Java语言的特点

一、Java语言特点

Java是一种跨平台，适合于分布式计算环境的面向对象编程语言。

具体来说，它具有如下特性：

简单性、面向对象、分布式、解释型、可靠、安全、平台无关、可移植、高性能、多线程、动态性等。

下面我们将重点介绍Java语言的面向对象、平台无关、分布式、多线程、可靠和安全等特性。

1.面向对象

面向对象其实是现实世界模型的自然延伸。现实世界中任何实体都可以看作是对象。对象之间通过消息相互作用。另外，现实世界中任何实体都可归属于某类事物，任何对象都是某一类事物的实例。如果说传统的过程式编程语言是以过程为中心以算法为驱动的话，面向对象的编程语言则是以对象为中心以消息为驱动。用公式表示，过程式编程语言为：程序=算法+数据；面向对象编程语言为：程序=对象+消息。

所有面向对象编程语言都支持三个概念：封装、多态性和继承，Java也不例外。现实世界中的对象均有属性和行为，映射到计算机程序上，属性则表示对象的数据，行为表示对象的方法（其作用是处理数据或同外界交互）。所谓封装，就是用一个自主式框架把对象的数据和方法联在一起形成一个整体。可以说，对象是支持封装的手段，是封装的基本单位。Java语言的封装性较强，因为Java无全程变量，无主函数，在Java中绝大部分成员是对象，只有简单的数字类型、字符类型和布尔类型除外。而对于这些类型，Java也提供了相应的对象类型以便与其他对象交互操作。

多态性就是多种表现形式，具体来说，可以用“一个对外接口，多个内在实现方法”表示。举一个例子，计算机中的堆栈可以存储各种格式的数据，包括整型，浮点或字符。不管存储的是何种数据，堆栈的算法实现是一样的。针对不同的数据类型，编程人员不必手工选择，只需使用统一接口名，系统可自动选择。运算符重载（operatoroverload)一直被认为是一种优秀的多态机制体现，但由于考虑到它会使程序变得难以理解，所以Java最后还是把它取消了。

继承是指一个对象直接使用另一对象的属性和方法。事实上，我们遇到的很多实体都有继承的含义。例如，若把汽车看成一个实体，它可以分成多个子实体，如：卡车、公共汽车等。这些子实体都具有汽车的特性，因此，汽车是它们的“父亲”，而这些子实体则是汽车的“孩子”。Java提供给用户一系列类（class），Java的类有层次结构，子类可以继承父类的属性和方法。与另外一些面向对象编程语言不同，Java只支持单一继承。

2�平台无关性

Java是平台无关的语言是指用Java写的应用程序不用修改就可在不同的软硬件平台上运行。平台无关有两种：源代码级和目标代码级。C和C++具有一定程度的源代码级平台无关，表明用C或C++写的应用程序不用修改只需重新编译就可以在不同平台上运行。

Java主要靠Java虚拟机（JVM）在目标码级实现平台无关性。JVM是一种抽象机器，它附着在具体操作系统之上，本身具有一套虚机器指令，并有自己的栈、寄存器组等。但JVM通常是在软件上而不是在硬件上实现。（目前，SUN系统公司已经设计实现了Java芯片，主要使用在网络计算机NC上。

另外，Java芯片的出现也会使Java更容易嵌入到家用电器中。）JVM是Java平台无关的基础，在JVM上，有一个Java解释器用来解释Java编译器编译后的程序。Java编程人员在编写完软件后，通过Java编译器将Java源程序编译为JVM的字节代码。任何一台机器只要配备了Java解释器，就可以运行这个程序，而不管这种字节码是在何种平台上生成的。另外，Java采用的是基于IEEE标准的数据类型。通过JVM保证数据类型的一致性，也确保了Java的平台无关性。

Java的平台无关性具有深远意义。首先，它使得编程人员所梦寐以求的事情（开发一次软件在任意平台上运行）变成事实，这将大大加快和促进软件产品的开发。其次Java的平台无关性正好迎合了“网络计算机”思想。如果大量常用的应用软件（如字处理软件等）都用Java重新编写，并且放在某个Internet服务器上，那么具有NC的用户将不需要占用大量空间安装软件，他们只需要一个

Java解释器，每当需要使用某种应用软件时，下载该软件的字节代码即可，运行结果也可以发回服务器。目前，已有数家公司开始使用这种新型的计算模式构筑自己的企业信息系统。

3�分布式

分布式包括数据分布和操作分布。数据分布是指数据可以分散在网络的不同主机上，操作分布是指把一个计算分散在不同主机上处理。

Java支持WWW客户机/服务器计算模式，因此，它支持这两种分布性。对于前者，Java提供了一个叫作URL的对象，利用这个对象，你可以打开并访问具有相同URL地址上的对象，访问方式与访问本地文件系统相同。对于后者，Java的applet小程序可以从服务器下载到客户端，即部分计算在客户端进行，提高系统执行效率。

Java提供了一整套网络类库，开发人员可以利用类库进行网络程序设计，方便得实现Java的分布式特性。

4�可靠性和安全性

Java最初设计目的是应用于电子类消费产品，因此要求较高的可靠性。Java虽然源于C++，但它消除了许多C++不可靠因素，可以防止许多编程错误。首先，Java是强类型的语言，要求显式的方法声明，这保证了编译器可以发现方法调用错误，保证程序更加可靠；其次，Java不支持指针，这杜绝了内存的非法访问；第三，Java的自动单元收集防止了内存丢失等动态内存分配导致的问题；第四，Java解释器运行时实施检查，可以发现数组和字符串访问的越界，最后，Java提供了异常处理机制，程序员可以把一组错误代码放在一个地方，这样可以简化错误处理任务便于恢复。

由于Java主要用于网络应用程序开发，因此对安全性有较高的要求。如果没有安全保证，用户从网络下载程序执行就非常危险。Java通过自己的安全机制防止了病毒程序的产生和下载程序对本地系统的威胁破坏。当Java字节码进入解释器时，首先必须经过字节码校验器的检查，然后，Java解释器将决定程序中类的内存布局，随后，类装载器负责把来自网络的类装载到单独的内存区域，避免应用程序之间相互干扰破坏。最后，客户端用户还可以限制从网络上装载的类只能访问某些文件系统。

上述几种机制结合起来，使得Java成为安全的编程语言。

5�多线程

线程是操作系统的一种新概念，它又被称作轻量进程，是比传统进程更小的可并发执行的单位。

C和C++采用单线程体系结构，而Java却提供了多线程支持。

Java在两方面支持多线程。一方面，Java环境本身就是多线程的。若干个系统线程运行负责必要的无用单元回收，系统维护等系统级操作；另一方面，Java语言内置多线程控制，可以大大简化多线程应用程序开发。Java提供了一个类Thread，由它负责启动运行，终止线程，并可检查线程状态。Java的线程还包括一组同步原语。这些原语负责对线程实行并发控制。利用Java的多线程编程接口，开发人员可以方便得写出支持多线程的应用程序，提高程序执行效率。必须注意地是，Java的多线程支持在一定程度上受运行时支持平台的限制。例如，如果操作系统本身不支持多线程，Java的多线程特性可能就表现不出来。

二、Java小程序和应用程序

用Java可以写两种类型的程序：小程序（又叫JavaApplet）和应用程序（JavaApplication）。小程序是嵌入在HTML文档中的Java程序；而Java应用程序是从命令行运行的程序。对Java而言，Java小程序的大小和复杂性都没有限制。事实上，Java小程序有些方面比Java应用程序更强大。但是由于目前Internet通讯速度有限，因此大多数小程序规模较小。小程序和应用程序之间的技术差别在于运行环境。

Java应用程序运行在最简单的环境中，它的唯一外部输入就是命令行参数。另一方面，Java小程序则需要来自Web浏览器的大量信息：它需要知道何时启动，何时放入浏览器窗口，何处，何时激活关闭。由于这两种不同的执行环境，小程序和应用程序的最低要求不同。

由于WWW使小程序的发布十分便利，因此小程序更适合作为Internet上的应用程序。相反，非网络系统和内存较小的系统更适合用Java应用程序而较少用Java小程序实现。另外，Java应用程序也很容易以Internet为基础环境，事实上有些优秀的Java应用程序正是如此。

华为服务器32根内存插法

华为服务器32根内存插法

行其他指令和内存引用，这就导致了指令和内存引用的乱序执行。

为了解决这一内存乱序问题，引入了各种同步原语，这些原语通过使用内存屏障来实现多处理器之间内存访问的顺序一致性。

本章以c/c++语言为例阐述内屏屏障基本原理和使用方法，Java语言已使用JDK对屏障原语进行了适配，代码调用及相关知识可参考Java同步原语。

内存屏障

内存屏障（Memory barrier）

每个CPU都会有自己的缓存（有的甚至L1,L2,L3），缓存的目的就是为了提高性能，避免每次都要向内存取。但是这样的弊端也很明显：不能实时的和内存发生信息交换，分在不同CPU执行的不同线程对同一个变量的缓存值不同。

用volatile关键字修饰变量可以解决上述问题，那么volatile是如何做到这一点的呢？那就是内存屏障，内存屏障是硬件层的概念，不同的硬件平台实现内存屏障的手段并不是一样，java通过屏蔽这些差异，统一由jvm来生成内存屏障的指令。

硬件层的内存屏障分为两种：Load Barrier 和 Store Barrier即读屏障和写屏障。

内存屏障有两个作用：

对于Load Barrier来说，在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制从新从主内存加载数据；

对于Store Barrier来说，在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见。

java的内存屏障通常所谓的四种即LoadLoad,StoreStore,LoadStore,StoreLoad实际上也是上述两种的组合，完成一系列的屏障和数据同步功能。

LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。

LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。 它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

  volatile的内存屏障策略非常严格保守，非常悲观且毫无安全感的心态：

由于内存屏障的作用，避免了volatile变量和其它指令重排序、线程之间实现了通信，使得volatile表现出了锁的特性。

对于final域，编译器和CPU会遵循两个排序规则：

总之上面规则的意思可以这样理解，必需保证一个对象的所有final域被写入完毕后才能引用和读取。这也是内存屏障的起的作用：

写final域：在编译器写final域完毕，构造体结束之前，会插入一个StoreStore屏障，保证前面的对final写入对其他线程/CPU可见，并阻止重排序。

读final域：在上述规则2中，两步操作不能重排序的机理就是在读final域前插入了LoadLoad屏障。

X86处理器中，由于CPU不会对写-写操作进行重排序，所以StoreStore屏障会被省略；而X86也不会对逻辑上有先后依赖关系的操作进行重排序，所以LoadLoad也会变省略。

关于java同步屏障和java 同步屏障的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。