java在编程上有什么安全缺陷
发布网友
发布时间：2022-04-27 03:03
共3个回答
懂视网
时间：2022-05-07 13:19
Java 编程语言的线程模型可能是此语言中最薄弱的部分。它完全不适合实际复杂程序的要求，而且也完全不是面向对象的。本文建议对 Java 语言进行重大修改和补充，以解决这些问题。
Java 语言的线程模型是此语言的一个最难另人满意的部分。尽管 Java 语言本身就支持线程编程是件好事，但是它对线程的语法和类包的支持太少，只能适用于极小型的应用环境。
关于 Java 线程编程的大多数书籍都长篇累牍地指出了 Java 线程模型的缺陷，并提供了解决这些问题的急救包(Band-Aid/邦迪创可贴)类库。我称这些类为急救包，是因为它们所能解决的问题本应是由 Java 语言本身语法所包含的。从长远来看，以语法而不是类库方法，将能产生更高效的代码。这是因为编译器和 Java 虚拟器 (JVM) 能一同优化程序代码，而这些优化对于类库中的代码是很难或无法实现的。
Allen Holub 指出，在我的《Taming Java Threads 》（请参阅 参考资料 ）书中以及本文中，我进一步建议对 Java 编程语言本身进行一些修改，以使得它能够真正解决这些线程编程的问题。本文和我这本书的主要区别是，我在撰写本文时进行了更多的思考, 所以对书中的提议加以了提高。这些建议只是尝试性的 -- 只是我个人对这些问题的想法，而且实现这些想法需要进行大量的工作以及同行们的评价。但这是毕竟是一个开端，我有意为解决这些问题成立一个专门的工作组，如果您感兴趣，请发 e-mail 到 threading@holub.com 。一旦我真正着手进行，我就会给您发通知。
这里提出的建议是非常大胆的。有些人建议对 Java 语言规范 (JLS)（请参阅参考资料 ）进行细微和少量的修改以解决当前模糊的 JVM 行为，但是我却想对其进行更为彻底的改进。
在实际草稿中，我的许多建议包括为此语言引入新的关键字。虽然通常要求不要突破一个语言的现有代码是正确的，但是如果该语言的并不是要保持不变以至于过时的话，它就必须能引入新的关键字。为了使引入的关键字与现有的标识符不产生冲突，经过细心考虑，我将使用一个 ($) 字符，而这个字符在现有的标识符中是非法的。(例如，使用 $task，而不是 task)。此时需要编译器的命令行开关提供支持，能使用这些关键字的变体，而不是忽略这个美元符号。
task（任务）的概念
Java 线程模型的根本问题是它完全不是面向对象的。面向对象 (OO) 设计人员根本不按线程角度考虑问题；他们考虑的是同步 信息 异步 信息（同步信息被立即处理 -- 直到信息处理完成才返回消息句柄；异步信息收到后将在后台处理一段时间 -- 而早在信息处理结束前就返回消息句柄）。Java 编程语言中的 Toolkit.getImage() 方法就是异步信息的一个好例子。 getImage() 的消息句柄将被立即返回，而不必等到整个图像被后台线程取回。
这是面向对象 (OO) 的处理方法。但是，如前所述，Java 的线程模型是非面向对象的。一个 Java 编程语言线程实际上只是一个run() 过程，它调用了其它的过程。在这里就根本没有对象、异步或同步信息以及其它概念。
对于此问题，在我的书中深入讨论过的一个解决方法是，使用一个Active_object。 active 对象是可以接收异步请求的对象，它在接收到请求后的一段时间内以后台方式得以处理。在 Java 编程语言中，一个请求可被封装在一个对象中。例如，你可以把一个通过 Runnable 接口实现的实例传送给此 active 对象，该接口的 run() 方法封装了需要完成的工作。该 runnable 对象被此 active 对象排入到队列中，当轮到它执行时，active 对象使用一个后台线程来执行它。
在一个 active 对象上运行的异步信息实际上是同步的，因为它们被一个单一的服务线程按顺序从队列中取出并执行。因此，使用一个 active 对象以一种更为过程化的模型可以消除大多数的同步问题。
在某种意义上，Java 编程语言的整个 Swing/AWT 子系统是一个 active 对象。向一个 Swing 队列传送一条讯息的唯一安全的途径是，调用一个类似SwingUtilities.invokeLater() 的方法，这样就在 Swing 事件队列上发送了一个 runnable 对象，当轮到它执行时， Swing 事件处理线程将会处理它。
那么我的第一个建议是，向 Java 编程语言中加入一个task （任务）的概念，从而将active 对象集成到语言中。( task的概念是从 Intel 的 RMX 操作系统和 Ada 编程语言借鉴过来的。大多数实时操作系统都支持类似的概念。）
一个任务有一个内置的 active 对象分发程序，并自动管理那些处理异步信息的全部机制。
定义一个任务和定义一个类基本相同，不同的只是需要在任务的方法前加一个asynchronous 修饰符来指示 active 对象的分配程序在后台处理这些方法。
所有的写请求都用一个dispatch() 过程调用被放在 active-object 的输入队列中排队。在后台处理这些异步信息时出现的任何异常 (exception) 都由 Exception_handler 对象处理，此 Exception_handler 对象被传送到 File_io_task 的构造函数中。
这种基于类的处理方法，其主要问题是太复杂了 -- 对于一个这样简单的操作，代码太杂了。向 Java 语言引入$task 和 $asynchronous 关键字后，就可以按下面这样重写以前的代码：
注意，异步方法并没有指定返回值，因为其句柄将被立即返回，而不用等到请求的操作处理完成后。所以，此时没有合理的返回值。对于派生出的模型，$task 关键字和 class 一样同效： $task 可以实现接口、继承类和继承的其它任务。标有 asynchronous 关键字的方法由 $task 在后台处理。其它的方法将同步运行，就像在类中一样。
$task关键字可以用一个可选的 $error 从句修饰 (如上所示)，它表明对任何无法被异步方法本身捕捉的异常将有一个缺省的处理程序。我使用 $ 来代表被抛出的异常对象。如果没有指定 $error 从句，就将打印出一个合理的出错信息（很可能是堆栈跟踪信息）。
注意，为确保线程安全，异步方法的参数必须是不变 (immutable) 的。运行时系统应通过相关语义来保证这种不变性（简单的复制通常是不够的）。
所有的 task 对象必须支持一些伪信息 (pseudo-message)。
除了常用的修饰符（public 等)， task 关键字还应接受一个 $pooled(n) 修饰符，它导致 task 使用一个线程池，而不是使用单个线程来运行异步请求。 n 指定了所需线程池的大小；必要时，此线程池可以增加，但是当不再需要线程时，它应该缩到原来的大小。伪域 (pseudo-field) $pool_size 返回在 $pooled(n) 中指定的原始 n 参数值。
在《Taming Java Threads 》的第八章中，我给出了一个服务器端的 socket 处理程序，作为线程池的例子。它是关于使用线程池的任务的一个好例子。其基本思路是产生一个独立对象，它的任务是监控一个服务器端的 socket。每当一个客户机连接到服务器时，服务器端的对象会从池中抓取一个预先创建的睡眠线程，并把此线程设置为服务于客户端连接。socket 服务器会产出一个额外的客户服务线程，但是当连接关闭时，这些额外的线程将被删除。
Socket_server对象使用一个独立的后台线程处理异步的 listen() 请求，它封装 socket 的“接受”循环。当每个客户端连接时， listen() 请求一个 Client_handler 通过调用 handle() 来处理请求。每个 handle() 请求在它们自己的线程中执行（因为这是一个 $pooled 任务)。
注意，每个传送到$pooled $task 的异步消息实际上都使用它们自己的线程来处理。典型情况下，由于一个 $pooled $task 用于实现一个自主操作；所以对于解决与访问状态变量有关的潜在的同步问题，最好的解决方法是在 $asynchronous 方法中使用 this 是指向的对象的一个独有副本。这就是说，当向一个 $pooled $task 发送一个异步请求时，将执行一个 clone() 操作，并且此方法的 this 指针会指向此克隆对象。线程之间的通信可通过对 static 区的同步访问实现。
热心网友
时间：2022-05-07 10:27
就其自身来说，并发编程是一种技术，提供了操作的同时执行，不论是在单一系统上还是分布在大量系统上。这类操作实际是一些指令顺序，例如单独某个顶级任务的子任务，这类操作能够并行执行，或者是作为线程，或者是作为进程。线程和进程之间的本质区别在于：进程通常是独立的(例如独立的地址空间)，所以只能通过系统提供的进程间通信机制进行交互，而线程通常共享单一进程的状态信息，能够直接共享系统资源和内存中的对象。
可以使用下面两种方法之一，通过多个进程来实现并发。第一种方法是在同一个处理器上运行进程，由操作系统处理进程之间的上下文环境切换。(可以理解，这种切换要比同一进程内多线程之间的上下文环境切换更慢。)第二种方法是构建大规模的并行和复杂的分布式系统，在不同的物理处理器上运行多个进程。
从内建支持的角度来说，Java 语言通过线程提供并发编程;每个 JVM 都能支持许多线程同时执行。可以用以下两种方法之一在 Java 语言中创建线程：
继承 java.lang.Thread 类。在这种情况下，已经重写的子类的 run() 方法必须包含实现线程运行时行为的代码。要执行这个代码，需要实例化子类对象，然后调用对象的 start() 方法，这样就可以在内部执行 run() 方法了。
创建 Runnable 接口的定制实现。这个接口只包含一个 run() 方法，在这个方法中，要放置应用程序代码。要执行这个代码，需要实例化实现类的对象，然后在创建新 Thread 时，把对象作为构造函数的参数传入。然后调用新创建的线程对象的 start() 方法，开始执行控制的新线程。
线程安全性和同步
如果 Java 对象中的某个方法能够安全地运行在多线程环境中，那么就称该方法是 线程安全的。要获得这种安全性，必须有一种机制，通过该机制，运行同一方法的多个线程就能够同步其操作，这样，在访问相同的对象或代码行时，就会只允许一个线程被处理。这种同步要求线程使用叫作 信号 的对象彼此进行沟通。
有一种类型的信号叫作 互斥信号 或 互斥体。顾名思义，这个信号对象的拥有权是互斥的，也就是说，在任意指定时间，只有一个线程能够拥有互斥体。其他想获得所有权的线程会被阻塞，它们必须等待，直到拥有互斥体的线程释放互斥体。如果多个线程按顺序排队等候同一互斥体，那么在当前拥有者释放它的时候，只有一个等候线程能够得到它;其他线程将继续阻塞。
在 1970 年代初，C.A.R. Hoare 和其他人共同开发了一个叫作 监视器 的概念。一个 监视器 就是一个代码主体，它的访问受到互斥体的保护。任何想执行这个代码的线程，都必须在代码块顶部得到关联的互斥体，然后在底部再释放它。因为在指定时间只有一个线程能够拥有互斥体，所以这就有效地保证了只有拥有它的线程才能执行监视器的代码块。(受保护的代码不需要相邻 —— 例如，Java 语言中的每个对象都有一个与之关联的监视器。)
任何想在 Java 语言中进行线程编程的开发人员，都会立即把上面的内容当成 synchronized 关键字所带来的效果。可以确保包含在 synchronized 块中的 Java 代码在指定时间只被一个线程执行。在内部，可以由运行时将 synchronized 关键字转换成某一种情况：所有的竞争线程都试图获得与它们(指线程)正在操作的对象实例关联的那个(惟一的一个)互斥体。成功得到互斥体的线程将运行代码，然后在退出 synchronized 块时释放互斥体。
等候和通知
wait/notify 构造在 Java 语言的线程间通信机制中也扮演了重要的角色。基本的想法是：一个线程需要的某个条件可以由另外一个线程促成。这样，条件的 wait 就可以得到满足。一旦条件为真，那么引发条件的线程就会 notify 等候线程苏醒，并从中止的地方继续进行。
wait/notify 机制要比 synchronized 机制更难理解和判断。要想判断出使用 wait/notify 的方法的行为逻辑，就要求判断出使用它的所有方法的逻辑。一次判断一个方法，把该方法和其他方法隔离开，是对整体系统行为得出错误结论的可靠方式。显然，这样做的复杂性会随着要判断的方法的数量增长而迅速提高。
线程状态
我前面提到过，必须调用新创建的线程的 start() 方法来启动它的执行。但是，仅仅是调用 start() 方法并不意味着线程会立即开始运行。这个方法只是把线程的状态从 new 变成 runnable。只有在操作系统真正安排线程执行的时候，线程状态才会变成 running (从 runnable)。
典型的操作系统支持两种线程模型 —— 协作式和抢占式。在协作式 模型中，每个线程对于自己对 CPU 的控制权要保留多久、什么时候放弃有最终意见。在这个模型中，因为可能存在某个无赖线程占住控制权不放，所以其他线程可能永远无法得到运行。在 抢占式 模型中，操作系统本身采用基于时钟“滴答”的计时器，基于这个计时器，操作系统可以强制把控制权从一个线程转移到另外一个线程。在这种情况下，决定哪个线程会得到下一次控制权的调度策略就有可能基于各种指标，例如相对优先级、某个线程已经等待执行的时间长短，等等。
如果出于某些原因，处在 running 状态的线程需要等候某个资源(例如，等候设备的输入数据到达，或者等候某些条件已经设定的通知)，或者在试图获得互斥体的时候被阻塞，因此线程决定睡眠，那么这时它可以进入 blocked 状态。当睡眠周期到期、预期输入到达，或者互斥体当前的拥有者将其释放并通知等候线程可以再次夺取互斥体时，阻塞的线程重新进入 runnable 状态。
当线程的 run() 方法完成时(或者正常返回，或者抛出 RuntimeException 这样的未检测到异常)，线程将终止。这时，线程的状态是 dead。当线程死亡时，就不能通过再次调用它的 start() 方法来重新启动它，如果那么做，则会抛出 InvalidThreadStateException 异常。
四个常见缺陷
正如我已经展示过的，Java 语言中的多线程编程是通过语言支持的大量精心设计的构造实现的。另外，还设计了大量设计模式和指导原则，来帮助人们了解这种复杂性带来的许多缺陷。除此之外，多线程编程会很容易地在不经意间把细微的 bug 带进多线程代码，而且更重要的是，这类问题分析和调试起来非常困难。接下来要介绍的是用 Java 语言进行多线程编程时将会遇到(或者可能已经遇到过)的最常见问题的一个列表。
争用条件
据说 争用条件 存在于这样的系统中：多个线程之间存在对共享资源的竞争，而胜出者决定系统的行为。Allen Holub 在他撰写的文章 “programming Java threads in the real world” 提供了一个带有这样 bug 的简单的多线程程序示例。在冲突的访问请求之间进行不正确同步的另一个更可怕的后果是 数据崩溃，此时，共享的数据结构有一部分由一个线程更新，而另一部分由另一个线程更新。在这种情况下，系统的行为不是按照胜出线程的意图进行，系统根本不按照任何一个线程的意图行动，所以两个线程最后都将以失败告终。
死锁
死锁 的情况是指：线程由于等候某种条件变成真(例如资源可以使用)，但是它等候的条件无法变成真，因为能够让条件变成真的线程在等候第一个线程“做某件事”。这样，两个线程都在等候对方先采取第一步，所以都无法做事。
活动锁
活动锁 与 死锁 不同，它是在线程实际工作的时候发生的，但这时还没有完成工作。这通常是在两个线程交叉工作的时候发生，所以第一个线程做的工作被另一个线程取消。一个简单的示例就是：每个线程已经拥有了一个对象，同时需要另外一个线程拥有的另外一个对象。可以想像这样的情况：每个线程放下自己拥有的对象，捡起另外一个线程放下的对象。显然，这两个线程会永远都运行在上锁这一步操作上，结果是什么都做不成。(常见的真实示例就是，两个人在狭窄的走廊相遇。每个人都礼貌地让到另一边让对方先行，但却在相同的时间都让到同一边了，所以两个人还都没法通过。这种情况会持续一些时间，然后两个人都从这边闪到那边，结果还是一点进展也没有。)
资源耗尽
资源耗尽，又称为 线程耗尽，是 Java 语言的 wait/notify 原语无法保证 live-ness 的后果。Java 强制这些方法要拥有它们等候或通知的对象的锁。在某个线程上调用的 wait() 方法在开始等候之前必须释放监视器锁，然后在从方法返回并获得通知之后，必须再次重新获得锁。因此，Java 语言规范在锁本身之外，还描述了一套与每个对象相关的 等候集(wait set)。一旦线程释放了对象上的锁(在 wait 的调用之后)，线程就会放在这个等候集上。
多数 JVM 实现把等候线程放在队列中。所以，如果在通知发生的时候，还有其他线程在等候监视器，那么就会把一个新线程放在队列尾部，而它并不是下一个获得锁的线程。所以，等到被通知线程实际得到监视器的时候，通知该线程的条件可能已经不再为真，所以它不得不再次 wait。这种情况可能无限持续下去，从而造成运算工作上浪费(因为要反复把该线程放入等候集和从中取出)和线程耗尽。
贪心哲学家的寓言
演示这种行为的原型示例是 Peter Welch 教授描述的“聪明人没有鸡肉”。在这个场景中考虑的系统是一所由五位哲学家、一位厨师和一个食堂组成的学院。所有的哲学家(除了一位)都要想想(在代码示例中，考虑的时间是 3 秒)之后才去食堂取饭。而“贪心的”哲学家则不想把时间浪费在思考上 —— 相反，他一次又一次地回到食堂，企图拿到鸡肉来吃。
厨师按照一批四份的定量准备鸡肉，每准备好一批，就送到食堂。贪心的哲学家不断地去厨房，但他总是错过食物!事情是这样的：他第一次到的时候，时间太早，厨师还没开火。因此贪心的哲学家只好干等着(通过 wait() 方法调用)。在开饭的时候(通过 notify() 方法调用)，贪心的哲学家再一次回到食堂排队等候。但是这次，在他前来等候的时候，他的四位同事已经到了，所以他在食堂队列中的位置在他们后面。他的同事们把厨房送来的一批四份鸡肉全部拿走了，所以贪心的哲学家又要在一边等着了。 可怜(也可能是公平的) ，他永远处在这个循环之外。
验证的问题
一般来说，很难按照普通的规范对 Java 编程的多线程程序进行验证。同样，开发自动化工具对于常见的并发问题(例如死锁、活动锁和资源耗尽)进行完整而简单的分析也不太容易——特别是在任意 Java 程序中或者在缺乏并发的正式模型的时候。
更糟的是，并发性问题出了名的变化多端、难于跟踪。每个 Java 开发人员都曾经听说过(或者亲自编写过)这样的 Java 程序：经过严格分析，而且正常运行了相当一段时间，没有表现出潜在的死锁。然后突然有一天，问题发生了，结果弄得开发团队经历许多的不眠之夜来试图发现并修补根本原因。
一方面，多线程 Java 程序容易发生的错误非常不明显，有可能在任意什么时候发生。另一方面，完全有可能这些 bug 在程序中从不出现。问题取决于一些不可知的因素。多线程程序的复杂本质，使得人们很难有效地对其进行验证。没有一套现成的规则可以找出多线程代码中的这类问题，也无法确切地证明这些问题不存在，这些导致许多 Java 开发人员完全避开多线程应用程序的设计和开发，即使用并发和并行的方式对系统进行建模会非常棒，他们也不使用多线程。
确实想进行多线程编程的开发人员通常准备好了以下一个或两个解决方案(至少是一部分)：
长时间艰苦地测试代码，找出所有出现的并发性问题，诚心地希望到应用程序真正运行地时候已经发现并修复了所有这类问题。
大量运行设计模式和为多线程编程建立的指导原则。但是，这类指导原则只在整个系统都按照它们的规范设计的时候才有效，没有设计规则能够覆盖所有类型的系统。
虽然知道的人不多，但是对于编写(然后验证)正确的多线程应用程序这一问题，还有第三个选项。使用称为通信顺序进程( Communicating Sequential Processes，CSP)的精确的线程同步的数学理论，可以在设计时最好地处理死锁和活动锁之类的问题。CSP 由 C.A.R. Hoare 与 20 世纪 70 年代后期设计，CSP 提供了有效的方法，证明用它的构造和工具构建的系统可以免除并发的常见问题。
结束语
在这份面向 Java 程序员的 CSP 全面介绍中，我把重点放在克服多线程应用程序开发常见问题的第一步上，即了解这些问题。我介绍了 Java 平台上目前支持的多线程编程构造，解释了它们的起源，讨论了这类程序可能会有的问题。我还解释了用正式理论在任意的、大型的和复杂的应用程序中清除这些问题(即竞争冒险、死锁、活动锁和资源耗尽)或者证明这些问题不存在的困难。
热心网友
时间：2022-05-07 11:45
每一种语言都一样，都没有缺陷，有缺陷那说明程序的设计者没有考虑到
