zabjava的简单介绍

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

本文目录一览：

• 1、大数据专业主要学习什么语言？
• 2、关于java学习，有什么书籍或者教程推荐不啦？
• 3、Paxos，Raft，Zab强一致性协议-Zab篇
• 4、大数据适合零基础学习吗？
• 5、java 是什么语言写的
• 6、Java中如何从键盘接收一个字符

大数据专业主要学习什么语言？

学习大数据，首先我们要学习Java语言和Linux操作系统，这两个是学习大数据的基础，学习的顺序不分前后。

Java：大家都知道Java的方向有JavaSE、JavaEE、JavaME，学习大数据要学习那个方向呢？只需要学习Java的标准版JavaSE就可以了，像Servlet、JSP、Tomcat、Struts、Spring、Hibernate，Mybatis都是JavaEE方向的技术在大数据技术里用到的并不多，只需要了解就可以了，当然Java怎么连接数据库还是要知道的，像JDBC一定要掌握一下，有人说Hibernate或Mybites也能连接数据库啊，为什么不学习一下，我这里不是说学这些不好，而是说学这些可能会用你很多时间，到最后工作中也不常用，我还没看到谁做大数据处理用到这两个东西的，当然你的精力很充足的话，可以学学Hibernate或Mybites的原理，不要只学API，这样可以增加你对Java操作数据库的理解，因为这两个技术的核心就是Java的反射加上JDBC的各种使用。

Linux：因为大数据相关软件都是在Linux上运行的，所以Linux要学习的扎实一些，学好Linux对你快速掌握大数据相关技术会有很大的帮助，能让你更好的理解hadoop、hive、hbase、spark等大数据软件的运行环境和网络环境配置，能少踩很多坑，学会shell就能看懂脚本这样能更容易理解和配置大数据集群。还能让你对以后新出的大数据技术学习起来更快

关于java学习，有什么书籍或者教程推荐不啦？

java Netty实战课程java高性能分布式RPC教程课程  免费下载

链接:

提取码:kvvv

Java是一门面向对象的编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。Java语言作为静态面向对象编程语言的代表，极好地实现了面向对象理论，允许程序员以优雅的思维方式进行复杂的编程

Paxos，Raft，Zab强一致性协议-Zab篇

Zab也是一个 强一致性算法 ，也是(multi-)Paxos的一种，全称是Zookeeper atomic broadcast protocol，是Zookeeper内部用到的一致性协议。相比Paxos，也易于理解。其保证了消息的全局有序和因果有序，拥有着一致性。Zab和Raft也是非常相似的，只是其中有些概念名词不一样。

Role(or Status)

节点状态：

Leading ：说明当前节点为Leader

Following ：说明当前节点为Follower

Election ：说明节点处于选举状态。整个集群都处于选举状态中。

Epoch逻辑时钟

Epoch相当于paxos中的proposerID，Raft中的term，相当于一个国家，朝代纪元。

Quorums：

多数派，集群中超过半数的节点集合。

节点中的持久化信息：

history:  a log of transaction proposals accepted; 历史提议日志文件

acceptedEpoch:  the epoch number of the last NEWEPOCH message accepted; 集群中的最近最新Epoch

currentEpoch:  the epoch number of the last NEWLEADER message accepted; 集群中的最近最新Leader的Epoch

lastZxid:  zxid of the last proposal in the history log; 历史提议日志文件的最后一个提议的zxid

在 ZAB 协议的事务编号 Zxid 设计中， Zxid  是一个 64 位的数字，

低 32 位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加 1；

高 32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的ZXID，并从中读取 epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。

epoch：可以理解为当前集群所处的年代或者周期，每个 leader 就像皇帝，都有自己的年号，所以每次改朝换代，leader 变更之后，都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后，也没有人听他的了，因为 follower 只听从当前年代的 leader 的命令。

ZAB协议

Zab协议分为四个阶段

Phase 0: Leader election（选举阶段，Leader不存在）

节点在一开始都处于选举阶段，只要有一个节点得到超半数Quorums节点的票数的支持，它就可以当选 prospective  leader 。只有到达 Phase 3 prospective leader 才会成为 established  leader (EL)。

这一阶段的目的是就是为了选出一个 prospective leader（PL） ，然后进入下一个阶段。

协议并没有规定详细的选举算法，后面我们会提到实现中使用的  Fast Leader Election 。

Phase 1: Discovery（发现阶段，Leader不存在）

在这个阶段，PL收集Follower发来的acceptedEpoch(或者)，并确定了PL的Epoch和Zxid最大，则会生成一个NEWEPOCH分发给Follower，Follower确认无误后返回ACK给PL。

这个一阶段的主要目的是PL生成NEWEPOCH，同时更新Followers的acceptedEpoch，并寻找最新的historylog，赋值给PL的history。

这个阶段的根本：发现最新的history log，发现最新的history log，发现最新的history log。

一个 follower 只会连接一个 leader，如果有一个节点 f 认为另一个 follower 是 leader，f 在尝试连接 p 时会被拒绝，f 被拒绝之后，就会进入 Phase 0。

1PL         Followers

2|---------X--X--X        FOLLOWERINFO(F.acceptedEpoch)

3X---------|-|-|        NEWEPOCH(e′)

4|---------X--X--X        ACKEPOCH(F.currentEpoch, F.history, F.lastZxid)，接着PL寻找所有Follower和PL中最新的history赋值给PL.history

Phase 2: Synchronization（同步阶段，Leader不存在）

同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。只有当 quorum 都同步完成，PL才会成为EL。follower 只会接收 zxid 比自己的 lastZxid 大的提议。

这个一阶段的主要目的是同步PL的historylog副本。

1PL         Followers

2X---------|-|-|        NEWLEADER(e′ , L.history) 

3|---------X--X--X        ACKNEWLEADER(e′,L.history)

4X---------|-|-|        COMMIT message,Follow Deliver ⟨v, z⟩,PL-L

Phase 3: Broadcast（广播阶段，Leader存在）

到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

这个一阶段的主要目的是接受请求，进行消息广播

值得注意的是，ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK，只需要得到 quorum （超过半数的节点）的 ACK 就可以了。

1Client     Leader      Followers

2|         |          |  |  |

3   X--------|          |  |  |      write Request

4|         X---------|-|-|     sent Propose ⟨e′, ⟨v, z⟩⟩

5|         |---------X--X--X     Append proposal to F.history,Send ACK(⟨e′, ⟨v, z⟩⟩) to L

6|         X---------|-|-|     COMMIT(e′, ⟨v, z⟩),F Commit (deliver) transaction ⟨v, z⟩

zookeeper中zab协议的实现

协议的 Java 版本实现跟上面的定义有些不同，选举阶段使用的是 Fast Leader Election（FLE），它包含了 Phase 1 的发现职责。因为  FLE 会选举拥有最新提议历史的节点作为 leader，这样就省去了发现最新提议的步骤 。实际的实现将 Phase 1 和 Phase 2 合并为 Recovery Phase（恢复阶段）。所以，ZAB 的实现只有三个阶段：

Phase 1:Fast Leader Election(快速选举阶段，Leader不存在)

前面提到 FLE 会选举拥有最新提议历史（lastZixd最大）的节点作为 leader，这样就省去了发现最新提议的步骤。这是基于拥有最新提议的节点也有最新提交记录的前提。

每个节点会同时向自己和其他节点发出投票请求，互相投票。

选举流程：

选epoch最大的

epoch相等，选 zxid 最大的

epoch和zxid都相等，选择serverID最大的（就是我们配置zoo.cfg中的myid）

节点在选举开始都默认投票给自己，当接收其他节点的选票时，会根据上面的条件更改自己的选票并重新发送选票给其他节点，当有一个节点的得票超过半数，该节点会设置自己的状态为 leading，其他节点会设置自己的状态为 following。

Phase 2:Recovery Phase（恢复阶段，Leader不存在）

这一阶段 follower 发送它们的 lastZixd 给 leader，leader 根据 lastZixd 决定如何同步数据。这里的实现跟前面 Phase 2 有所不同：Follower 收到 TRUNC 指令会中止 L.lastCommittedZxid 之后的提议，收到 DIFF 指令会接收新的提议。

1L         Followers

2X-----------------          L.lastZxid ← ⟨L.lastZxid.epoch + 1, 0⟩

3|---------X--X--X        FOLLOWERINFO(F.lastZxid)

4X---------|-|-|        NEWEPOCH(L.lastZxid)

5X---------|-|-|        SNAP,DIFF or TRUNC指令

6|---------X--X--X        if TRUNC notAccept L.lastZxid else(DIFF) accept,commit proposal else(SNAP) ...

Phase 3:Broadcast Election(广播阶段，Leader存在)

同上

Leader故障

如果是Leader故障，首先进行Phase 1:Fast Leader Election，然后Phase 2:Recovery Phase，恢复阶段保证了如下两个问题，这两个问题同时也和Raft中的Leader故障解决的问题是一样的， 总之就是要保证Leader操作日志是最新的 ：

已经被处理的消息不能丢      

被丢弃的消息不能再次出现

总结

Zab和Raft都是强一致性协议，但是Zab和Raft的实质是一样的，都是mutli-paxos衍生出来的强一致性算法。简单而言，他们的算法都都是先通过Leader选举，选出一个Leader，然后Leader接受到客户端的提议时，都是先写入操作日志，然后再与其他Followers同步日志，Leader再commit提议，再与其他Followers同步提议。如果Leader故障，重新走一遍选举流程，选取最新的操作日志，然后同步日志，接着继续接受客户端请求等等。过程都是一样，只不过两个的实现方式不同，描述方式不同。 实现Raft的核心是Term，Zab的核心是Zxid，反正Term和Zxid都是逻辑时钟。

大数据适合零基础学习吗？

零基础可以学习大数据吗？答案是可以的。大数据就是升级版的Java，学习大数据一定要有Java基础。不过如果你是零基础学习大数据，那么也可以从Java开始学习，逐渐做到大数据，薪资会更高。

大数据这个行业成为很多小伙伴向往的行业，首先我想普及一下什么叫大数据，大数据顾名思义首先具有的特点是数据量多，指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

大数据行业薪资高为此吸引了很多的小伙伴，但是零基础可以学习大数据吗?零基础如何学习大数据?针对这点小编首先介绍一下Java和大数据之间的关系，当然有部分小伙伴把大数据称之为Java大数据。

Java工程师的发展：

初级Java工程师、中级Java工程师、高级Java工程师;而Java大数据工程师以后的发展，相比于Java而言，多了一个大数据的方向，利于想向大数据工程师转型的学习者。

因为想要成为大数据工程师，需要一定的编程基础，而Java语言又是现在大数据技术常用的开发语言，所以Java大数据是向大数据学习的奠基课程。

java 是什么语言写的

java 是什么语言写的

JAVA中就虚拟机是其它语言开发的，用的是C语言+汇编语言 基于此之上就是JAVA本身了 虚拟机只起到解析作用

另外，JAVA并不比C语言慢，说JAVA慢一般是九十年代那时候的JAVA， 而现在 在一段优秀的JAVA程序和C程序执行效率上来比较是没有多大差距的 并且现在JAVA已经可以像C语言那样，直接编译为可执行文件（不用虚拟机，跨平台为代价）了

不知道你看过 卓越编程之道二（运用底层思维编写高级代码） 没有，那里面详细的讲述了高级语言从编写到编译执行的过程，通过目标文件的反汇编对比，发现C，C++，JAVA，dephi等语言在同等质量下的目标文件长度上基本上没多大区别，一门语言的运行速度快慢，与你编写代码过程中是否符合编译器规则息息相关。 有空你可以去看看这本书。

glusterfs 是什么语言写的

glusterfs 是什么语言写的

使用opencv需要编译源码，得到库文件。可以用cmake构建项目后编译，也可以直接用官方提供的编译好的版本。

官方提供的编译库一般只是标准版本，没有附加某些库，比如tbb等，要想让opencv使用tbb等库，就只能自己构建项目后编译。

当然，一般使用的话，用官方提供的库即可。OpenCV2.3.1版本就提供编译好的库，可以直接设置使用。

bigtable是什么语言写的

不过有人大费周折为他建立了一个类似于“关于 Chuck Norris 的事实”这样的网站，这倒是件不同寻常的事。这是因为 Jeff Dean 是一位软件工程师

zookeeper是什么语言写的

本文是Jason Wilder对于常见的服务发现项目 Zookeeper ， Doozer ， Etcd 所写的一篇博客，其原文地址如下： Open-Source Service Discovery 。

服务发现是大多数分布式系统以及面向服务架构（SOA）的一个核心组成部分。这个难题，简单来说，可以认为是：当一项服务存在于多个主机节点上时，client端如何决策获取相应正确的IP和port。

在传统情况下，当出现服务存在于多个主机节点上时，都会使用静态配置的方法来实现服务信息的注册。但是当大型系统中，需要部署更多服务的时候，事情就显得复杂得多。在一个实时的系统中，由于自动或者人工的服务扩展，或者服务的新添加部署，还有主机的宕机或者被替换，服务的location信息可能会很频繁的变化。

在这样的场景下，为了避免不必要的服务中断，动态的服务注册和发现就显得尤为重要。

关于服务发现的话题，已经很多次被人所提及，而且也的确不断的在发展。现在，笔者介绍一下该领域内一些open-source或者被经常被世人广泛讨论的解决方案，尝试理解它们到底是如何工作的。特别的是，我们会较为专注于每一个解决方案的一致性算法，到底是强一致性，还是弱一致性；运行时依赖；client的集成选择；以后最后这些特性的折中情况。

本文首先从几个强一致性的项目于开始，比如Zookeeper，Doozer，Etcd，这些项目主要用于服务间的协调，同时又可用于服务的注册。

随后，本文将讨论一些在服务注册以及发现方面比较有意思的项目，比如：Airbnb的SmartStack，Netflix的Eureka，Bitly的NSQ，Serf，Spotify and DNS，最后是SkyDNS。

问题陈述

在定位服务的时候，其实会有两个方面的问题：服务注册（Service Registration）和服务发现（Service Discovery）。

服务注册—— 一个服务将其位置信息在中心注册节点注册的过程。该服务一般会将它的主机IP地址以及端口号进行注册，有时也会有服务访问的认证信息，使用协议，版本号，以及关于环境的一些细节信息。

服务发现—— client端的应用实例查询中心注册节点以获知服务位置的过程。

每一个服务的服务注册以及服务发现，都需要考虑一些关于开发以及运营方面的问题：

监控—— 当一个已注册完毕的服务失效的时候，如何处理。一些情况下，在一个设定的超时定时(timeout)后，该服务立即被一个其他的进程在中心注册节点处注销。这种情况下，服务通常需要执行一个心跳机制，来确保自身的存活状态；而客户端必然需要能够可靠处理失效的服务。

负载均衡—— 如果多个相同地位的服务都注册完毕，如何在这些服务之间均衡所有client的请求负载？如果有一个master节点的话，是否可以正确处理client访问的服务的位置。

集成方式—— 信息注册节点是否需要提供一些语言绑定的支持，比如说，只支持Java？集成的过程是否需要将注册过程以及发现过程的代码嵌入到你的应用程序中，或者使用一个类似于集成助手的进程？

运行时依赖—— 是否需要JVM，ruby或者其他在你的环境中并不兼容的运行时？

可用性考虑—— 如果系统失去一个节点的话，是否还能正常工作？系统是否可以实时更新或升级，而不造成任何系统的瘫痪？既然集群的信息注册节点是架构中的中心部分，那该模块是否会存在单点故障问题？

强一致性的Registries

首先介绍的三个服务注册系统都采用了强一致性协议，实际上为达到通用的效果，使用了一致性的数据存储。尽管我们把它们看作服务的注册系统，其实它们还可以用于协调服务来协助leader选举，以及在一个分布式clients的集合中做centralized locking。

Zookeeper

Zookeeper是一个集中式的服务，该服务可以维护服务配置信息，命名空间，提供分布式的同步，以及提供组化服务。Zookeeper是由Java语言实现，实现了强一致性（CP），并且是使用 Zab协议 在ensemble集群之间协调服务信息的变化。

Zookeeper在ensemble集群中运行3个，5个或者7个成员。众多client端为了可以访问ensemble，需要使用绑定特定的语言。这种访问形式被显性的嵌入到了client的应用实例以及服务中。

服务注册的实现主要是通过命令空间（namespace）下的 ephemeral nodes 。ephemeral nodes只有在client建立连接后才存在。当client所在节点启动之后，该client端会使用一个后台进程获取client的位置信息，并完成自身的注册。如果该client失效或者失去连接的时候，该ephemeral node就从树中消息。

服务发现是通过列举以及查看具体服务的命名空间来完成的。Client端收到目前所有注册服务的信息，无论一个服务是否不可用或者系统新添加了一个同类的服务。Client端同时也需要自行处理所有的负载均衡工作，以及服务的失效工作。

Zookeeper的API用起来可能并没有那么方便，因为语言的绑定之间可能会造成一些细小的差异。如果使用的是基于JVM的语言的话， Curator Service Discovery Extension 可能会对你有帮助。

由于Zookeeper是一个CP强一致性的系统，因此当网络分区（Partition）出故障的时候，你的部分系统可能将出出现不能注册的情况，也可能出现不能找到已存在的注册信息，即使它们可能在Partition出现期间仍然正常工作。特殊的是，在任何一个non-quorum端，任何读写都会返回一个错误信息。

Doozer

Doozer是一个一致的分布式数据存储系统，Go语言实现，通过 Paxos算法 来实现共识的强一致性系统。这个项目开展了数年之后，停滞了一段时间，而且现在也关闭了一些fork数，使得fork数降至160 。.不幸的是，现在很难知道该项目的实际发展状态，以及它是否适合使用于生产环境。

Doozer在集群中运行3，5或者7个节点。和Zookeeper类似，Client端为了访问集群，需要在自身的应用或者服务中使用特殊的语言绑定。

Doozer的服务注册就没有Zookeeper这么直接，因为Doozer没有那些ephemeral node的概念。一个服务可以在一条路径下注册自己，如果该服务不可用的话，它也不会自动地被移除。

现有很多种方式来解决这样的问题。一个选择是给注册进程添加一个时间戳和心跳机制，随后在服务发现进程中处理那些超时的路径，也就是注册的服务信息，当然也可以通过另外一个清理进程来实现。

服务发现和Zookeeper很类似，Doozer可以罗列出指定路径下的所有入口，随后可以等待该路径下的任意改动。如果你在注册期间使用一个时间戳和心跳，你就可以在服务发现期间忽略或者删除任何过期的入口，也就是服务信息。

和Zookeeper一样，Doozer是一个CP强一致性系统，当发生网络分区故障时，会导致同样的后果。

Etcd

Etcd 是一个高可用的K-V存储系统，主要应用于共享配置、服务发现等场景。Etcd可以说是被Zookeeper和Doozer催生而出。整个系统使用Go语言实现，使用Raft算法来实现选举一致，同时又具有一个基于HTTP+JSON的API。

Etcd，和Doozer和Zookeeper相似，通常在集群中运行3，5或者7个节点。client端可以使用一种特定的语言进行绑定，同时也可以通过使用HTTP客户端自行实现一种。

服务注册环节主要依赖于使用一个key TTL来确保key的可用性，该key TTL会和服务端的心跳捆绑在一起。如果一个服务在更新key的TTL时失败了，那么Etcd会对它进行超时处理。如果一个服务变为不可用状态，client会需要处理这样的连接失效，然后尝试另连接一个服务实例。

服务发现环节设计到罗列在一个目录下的所有key值，随后等待在该目录上的所有变动信息。由于API接口是基于HTTP的，所以client应用会的Etcd集群保持一个long-polling的连接。

由于Etcd使用 Raft一致性协议 ，故它应该是一个强一致性系统。Raft需要一个leader被选举，然后所有的client请求会被该leader所处理。然而，Etcd似乎也支持从non-leaders中进行读取信息，使用的方式是在读情况下提高可用性的未公开的一致性参数。在网络分区故障期间，写操作还是会被leader处理，而且同样会出现失效的情况。

delphi是什么语言写的

Object Pascal

jdk是什么语言写的

你猜～～

druid是什么语言写的

Druid是Java语言中最好的数据库连接池。Druid能够提供强大的监控和扩展功能。

EPM和BI是什么啊？是用java语言写的吗？

不全是java，epm有用.写的，但是绝大多少是用java。

BI设计到大数据，除了java还有一些新技术，比如scala和kalfka。

dos 是什么语言写的?

汇编语言，低级编辑语言

Api 是什么语言写的？

API肯定也是一种语言实现他具体功能的啊 .

相当于函数,不过我们只能调用,不知道如何实现的.

Java中如何从键盘接收一个字符

这篇教程非常详细了 借花献佛 :)

java控制台输入

0 引言

从控制台中读取数据是一个比较常用的功能，在 JDK 5.0 以前的版本中的实现是比较复杂的，需要手工处理系统的输入流。有意思的是，从 JDK 5.0 版本开始，能从控制台中输入数据的方法每增加一个版本号，就有一种新增的方法，这也增加了选择的种类，可以依据不同的要求来进行选择。下面来看一下，各个版本中如何从控制台中读取数据以及各自的优缺点。

1 JDK 1.4 及以下版本读取的方法

JDK 1.4 及以下的版本中要想从控制台中输入数据只有一种办法，即使用System.in获得系统的输入流，再桥接至字符流从字符流中读入数据。示例代码如下：

import java.io.IOException;

import java.io.InputStreamReader;

public class Test1 {

public static void main(String[] args) {

String str = readString("请输入字符串：");

System.out.println("readString 方法的输入：" + str);

}

private static String readString(String prompt) {

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

String str = null;

try {

System.out.print(prompt);

str = br.readLine();

} catch (IOException e) {

e.printStackTrace();

}

return str;

}

}

从上面的代码段来看，这种控制台输入的方法非常地麻烦，为了能读取整行的数据，采用了BufferedReader类来进行处理，而且在读取的过程中还需要捕获IOException。不过这是 JDK 1.4 及以下版本中从控制台读取数据唯一的办法。还有一种非控制台读入数据的办法，就是采用 Swing 中的JOptionPane，会弹出一个非常漂亮的输入对话框让使用者输入数据，但这是一种比较另类的做法，不推荐使用。

import javax.swing.JOptionPane;

public class Test2 {

public static void main(String[] args) {

String str = readStringFromDialog("请输入字符串：");

System.out.println("readStringFromDialog 方法的输入：" + str);

}

private static String readStringFromDialog(String prompt) {

return JOptionPane.showInputDialog(prompt);

}

}

上面的两种方法都有个共同的缺点——只能读取字符串，若需要读取其他类型的数据需要手工进行转换。

2 JDK 5.0 读取的方法

从 JDK 5.0 开始，基本类库中增加了java.util.Scanner类，根据它的 API 文档说明，这个类是采用正则表达式进行基本类型和字符串分析的文本扫描器。使用它的Scanner(InputStream source)构造方法，可以传入系统的输入流System.in而从控制台中读取数据。示例代码如下：

import java.util.Scanner;

public class Test3 {

public static void main(String[] args) {

String str = readString5("请输入字符串：");

System.out.println("readString5 方法的输入：" + str);

}

private static String readString5(String prompt) {

Scanner scanner = new Scanner(System.in);

System.out.print(prompt);

return scanner.nextLine();

}

}

从代码量上来看，Test3比Test1少了很多的代码，核心代码只有两行。其实并不是Scanner将控制台输入给简单化了，只是在其内部的实现中已经将IOException处理了，而且采用InputStreamReader来一个字符一个字符进行扫描读取的（嘿嘿，它本身就是个扫描器），只是 Scanner做了更高层次的封装。

Scanner不仅可以从控制台中读取字符串，还可以读取除char之外的其他七种基本类型和两个大数字类型，并不需要显式地进行手工转换。 Scanner不单单只能扫描控制台中输入的字符，它还可以让读入的字符串匹配一定的正则表达式模式，如果不匹配时将抛出 InputMismatchException异常。

使用System.in作为它的构造参数时，它只扫描了系统输入流中的字符。它还有其他的构造，分别可以从文件或者是字符串中扫描分析字符串的，具体的使用方法可以参考 API 文档说明。

3 JDK 6.0 读取的方法

从 JDK 6.0 开始，基本类库中增加了java.io.Console类，用于获得与当前 Java 虚拟机关联的基于字符的控制台设备。在纯字符的控制台界面下，可以更加方便地读取数据。示例代码如下：

import java.io.Console;

import java.util.Scanner;

public class Test4 {

public static void main(String[] args) {

String str = readString6("请输入字符串：");

System.out.println("readString6 方法的输入：" + str);

}

private static String readString6(String prompt) {

Console console = System.console();

if (console == null) {

throw new IllegalStateException("不能使用控制台");

}

return console.readLine(prompt);

}

}

在Test1和Test3中，输入数据前的提示信息需要使用System.out.print();来输出，但是使用基于Console的Test4类，可以在方法参数中直接放入提示信息。

如果需要在控制台中输入密码等敏感信息的话，像在浏览器或者是应用程序中那样显示替代字符，在 JDK 6.0 以前的做法是相当麻烦的（具体的做法可以参考《Java 编程语言中的口令屏蔽》一文），而使用Console类的readPassword()方法可以在控制台上不回显地输入密码，并将密码结果保存在char 数组中，根据 API 文档的建议，在使用后应立即将数组清空，以减少其在内存中占用的时间，以便增强安全性。

但是，Console也有一些缺点，根据ConsoleAPI 文档的说明：

虚拟机是否具有控制台取决于底层平台，还取决于调用虚拟机的方式。如果虚拟机从一个交互式命令行开始启动，且没有重定向标准输入和输出流，那么其控制台将存在，并且通常连接到键盘并从虚拟机启动的地方显示。如果虚拟机是自动启动的（例如，由后台作业调度程序启动），那么它通常没有控制台。

通过上面的文档说明可以看出，在使用 IDE 的情况下，是无法获取到Console实例的，原因在于在 IDE 的环境下，重新定向了标准输入和输出流，也是就是将系统控制台上的输入输出重定向到了 IDE 的控制台中。因此，在 IDE 中不能使用这个程序，而Test1和Test3就没有这种限制。

4 总结

以上囊括了 Java 中各种版本从控制台中读入数据的方法，将对它们的优缺点进行了分析。下面给出了一些使用建议，可供参考：

JRE 1.4 或以下版本的情况下，没得选择只能采用Test1或者是非控制台读入的Test2的方法。

JRE 5.0 的情况下，建议使用基于Scanner的Test3的方法，更方便地进行数据读取。

JRE 6.0 的情况，并且只在字符界面的控制台下运行时，采用Test4的方法，如果需要读入像密码之类的敏感数据，为了安全性考虑也必须使用Test4或者是自行实现。如果需要读入除字符串类型之外的其他数据类型，建议使用基于Scanner的控制台输入。

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