- 使用 Spring Initializr 创建 Spring Boot 应用程序
- 在Spring Boot中配置Cassandra
- 在 Spring Boot 上配置 Tomcat 连接池
- 将Camel消息路由到嵌入WildFly的Artemis上
转载:Flink 源码阅读笔记(15)- Flink SQL 整体执行框架
在数据处理领域,无论是实时数据处理还是离线数据处理,使用 SQL 简化开发将会是未来的整体发展趋势。尽管 SQL 简化了使用的门槛,但是如何将 SQL 等价转换到现有的数据处理引擎中却并非易事,尤其是在流式数据处理框架中。
最近,Flink 发布了备受瞩目的 1.9 版本,由于阿里开源了其内部的 Blink 分支,Flink SQL 的功能得到了进一步的改进和增强。尽管在这个版本中,Blink 仍然只是作为一个预览的版本发布,但是 Blink 后续将会成为 Flink 社区的主要开发方向。接下来,我们将主要基于 Blink 来介绍 Flink SQL 的整体执行流程。
SQL 的执行流程一般分为四个主要的阶段,Flink 主要依赖于 Calicte 来完成这一流程:
Parse
:语法解析,把 SQL 语句转换成为一个抽象语法树(AST),在 Calcite 中用 SqlNode
来表示;
Validate
:语法校验,根据元数据信息进行验证,例如查询的表、使用的函数是否存在等,校验之后仍然是 SqlNode 构成的语法树;
Optimize
:查询计划优化,这里其实包含了两部分,1)首先将 SqlNode 语法树转换成关系表达式 RelNode 构成的逻辑树,2)然后使用优化器基于规则进行等价变换,例如我们比较熟悉的谓词下推、列裁剪等,经过优化器优化后得到最优的查询计划;
Execute
:将逻辑查询计划翻译成物理执行计划,生成对应的可执行代码,提交运行。
Flink SQL 的处理也大体遵循上述处理流程。Calcite 自身的概念较为庞杂,尤其是其内部使用的 HepPlanner
和 VolcanoPlanner
优化器更是非常复杂,但好在 Calcite
的可扩展性很强,优化器的优化规则也可以很容易地进行扩展,因此如果只是了解 Flink SQL 的基本原理和扩展方法,也无需对 Calcite 的代码了解的非常透彻。关于 Calcite 的基本介绍可以参考这个Slide。
通过对 table 模块进行拆分和重构,Flink SQL 抽象出了 Planner 接口和 Executor 接口,可以支持多个不同的 Runner
,用户可以自行选择希望使用的 Runner。不同的 Runner 只需要正确地实现这两个接口即可。在 1.9 版本中,Flink 提供了两套 SQL Runner,分别对应之前社区已有的 Flink SQL Runner 和新的 Blink Runner,Blink Runner 目前只是一个预览版本,在后续的迭代中会取代现有的 Flink Runner。
public interface Planner {
List<Operation> parse(String statement);
List<Transformation<?>> translate(List<ModifyOperation> modifyOperations);
}
Planner 接口完成 SQL 的解析和逻辑计划的转换,最终得到构建 Flink 计算逻辑的转换算子。
public interface Executor {
void apply(List<Transformation<?>> transformations);
JobExecutionResult execute(String jobName) throws Exception;
}
Executor 接口将 Planner 接口翻译出的算子应用到底层运行时环境中,并提供启动程序的入口。
SQL 的解析在 PlannerBase.parse() 中实现:1)首先使用 Calcite 的解析出抽象语法树 SqlNode,2)然后结合元数据对 SQL 语句进行验证,3)将 SqlNode 转换为 RelNode,4)并最终封装为 Flink 内部对查询操作的抽象 QueryOperation。
abstract class PlannerBase(
executor: Executor,
config: TableConfig,
val functionCatalog: FunctionCatalog,
catalogManager: CatalogManager,
isStreamingMode: Boolean)
extends Planner {
override def parse(stmt: String): util.List[Operation] = {
val planner = createFlinkPlanner
// 1)这一步解析得到 SqlNode
val parsed = planner.parse(stmt)
// 使用 SqlToOperationConverter 将 SqlNode 转化为 Operation
parsed match {
case insert: RichSqlInsert =>
List(SqlToOperationConverter.convert(planner, insert))
case query if query.getKind.belongsTo(SqlKind.QUERY) =>
//查询语句
List(SqlToOperationConverter.convert(planner, query))
case ddl if ddl.getKind.belongsTo(SqlKind.DDL) =>
List(SqlToOperationConverter.convert(planner, ddl))
case _ =>
throw new TableException(s"Unsupported query: $stmt")
}
}
}
public class SqlToOperationConverter {
public static Operation convert(FlinkPlannerImpl flinkPlanner, SqlNode sqlNode) {
// 2) 结合元数据验证 Sql 的合法性
final SqlNode validated = flinkPlanner.validate(sqlNode);
// 将 SqlNode 转化为 Operation
SqlToOperationConverter converter = new SqlToOperationConverter(flinkPlanner);
if (validated instanceof SqlCreateTable) {
return converter.convertCreateTable((SqlCreateTable) validated);
} if (validated instanceof SqlDropTable) {
return converter.convertDropTable((SqlDropTable) validated);
} else if (validated instanceof RichSqlInsert) {
return converter.convertSqlInsert((RichSqlInsert) validated);
} else if (validated.getKind().belongsTo(SqlKind.QUERY)) {
return converter.convertSqlQuery(validated);
} else {
throw new TableException("Unsupported node type "
+ validated.getClass().getSimpleName());
}
}
/** Fallback method for sql query. */
private Operation convertSqlQuery(SqlNode node) {
return toQueryOperation(flinkPlanner, node);
}
private PlannerQueryOperation toQueryOperation(FlinkPlannerImpl planner, SqlNode validated) {
// 3) 使用 SqlToRelConverter 将 SqlNode 转换成 RelNode
RelRoot relational = planner.rel(validated);
// 4) 将 RelNode 封装成 PlannerQueryOperation
return new PlannerQueryOperation(relational.project());
}
}
我们知道,Flink 借助于 Calcite 完成 SQl 的解析和优化,而后续的优化部分其实都是直接基于 RelNode
来完成的,那么这里为什么又多出了一个 QueryOperation
的概念呢?这主要是因为,Flink SQL 是支持 SQL 语句和 Table Api 接口混合使用的,在 Table Api 接口中,主要的操作都是基于 Operation 接口来完成的。
在将 SQL 语句解析成 Operation 后,为了得到 Flink 运行时的具体操作算子,需要进一步将 ModifyOperation
转换为 Transformation
。在 Blink 之前的 SQL Planner 中,都是基于 DataStream 或 DataSet API 完成运行时逻辑的构建;而 Blink 则使用更底层的 Transformation 算子。
注意,Planner.translate(List<ModifyOperation> modifyOperations)
方法接收的参数是 ModifyOperation
,ModifyOperation
对应的是一个 DML 的操作,在将查询结果插入到一张结果表或者转换为 DataStream 时,就会得到 ModifyOperation
。
转换的流程主要分为四个部分,即 1)将 Operation 转换为 RelNode,2)优化 RelNode,3)转换成 ExecNode,4)转换为底层的 Transformation 算子。
abstract class PlannerBase(
executor: Executor,
config: TableConfig,
val functionCatalog: FunctionCatalog,
catalogManager: CatalogManager,
isStreamingMode: Boolean)
extends Planner {
override def translate(
modifyOperations: util.List[ModifyOperation]): util.List[Transformation[_]] = {
if (modifyOperations.isEmpty) {
return List.empty[Transformation[_]]
}
mergeParameters()
// 1)将 Operation 转换为 RelNode
val relNodes = modifyOperations.map(translateToRel)
// 2)优化 RelNode
val optimizedRelNodes = optimize(relNodes)
// 3)转换成 ExecNode
val execNodes = translateToExecNodePlan(optimizedRelNodes)
// 4)转换为底层的 Transformation 算子
translateToPlan(execNodes)
}
}
首先需要进行的操作是将 Operation
转换为 RelNode
,这个转换操作借助 QueryOperationConverter
完成。Operation
其实类似于 SQL 语法树,也构成一个树形结构,并实现了访问者模式,支持使用 QueryOperationVisitor
遍历整棵树,QueryOperationConverter
实现了 QueryOperationVisitor
接口。对于 PlannerQueryOperation
,其内部封装的就是已经构建好的 RelNode
,直接取出即可;对于其它类型的 Operation
,则按需转换为对应的 RelNode
。
在得到 RelNode
后,就进入 Calcite
对 RelNode
的优化流程。在 Blink 中有一点特殊的地方在于,由于多个 RelNode 构成的树可能存在共同的“子树”
(例如将相同的查询结果输出到不同的结果表中,那么两个 LogicalSink 的子树就可能是共用的),Blink 使用了一种 CommonSubGraphBasedOptimizer
优化器,将拥有共同子树的 RelNode
看作一个 DAG 结构,并将 DAG 划分成 RelNodeBlock
,然后在RelNodeBlock
的基础上进行优化工作。每一个 RelNodeBlock 可以看作一个 RelNode 树进行优化,这和正常的 Calcite 处理流程还是保持一致的。
abstract class CommonSubGraphBasedOptimizer extends Optimizer {
override def optimize(roots: Seq[RelNode]): Seq[RelNode] = {
//以RelNodeBlock为单位进行优化,在子类中实现,StreamCommonSubGraphBasedOptimizer,BatchCommonSubGraphBasedOptimizer
val sinkBlocks = doOptimize(roots)
//获得优化后的逻辑计划
val optimizedPlan = sinkBlocks.map { block =>
val plan = block.getOptimizedPlan
require(plan != null)
plan
}
//将 RelNodeBlock 使用的中间表展开
expandIntermediateTableScan(optimizedPlan)
}
}
Caclite 对逻辑计划的优化是一套基于规则的框架,用户可以通过添加规则进行扩展,Flink 就是基于自定义规则来实现整个的优化过程。Flink 构造了一个链式的优化程序,可以按顺序使用多套规则集合完成 RelNode 的优化过程。在 FlinkStreamProgram 和 FlinkBatchProgram 中定义了一系列扩展规则,用于构造逻辑计划的优化器。与此同时,Flink 扩展了 RelNode,增加了 FlinkLogicRel 和 FlinkPhysicRel 这两类 RelNode,对应的 Convention 分别为 FlinkConventions.LOGICAL 和 FlinkConventions.STREAM_PHYSICAL (或FlinkConventions.BATCH_PHYSICAL)。在优化器的处理过程中,RelNode 会从 Calcite 内部定义的节点转换为 FlinkLogicRel 节点(FlinkConventions.LOGICAL),并最终被转换为 FlinkPhysicRel 节点(FlinkConventions.STREAM_PHYSICAL)。这两类转换规则分别对应 FlinkStreamRuleSets.LOGICAL_OPT_RULES 和 FlinkStreamRuleSets.PHYSICAL_OPT_RULES。在不考虑其它更复杂的性能优化的情况下,如果要扩展 Flink SQL 的语法规则,可以参考这两类规则来增加节点和转换规则。
以 Join 操作为例,首先经过 Calcite 解析后得到的节点为 LogicalJoin。 LogicalJoin 会匹配转换规则中的 FlinkLogicalJoinConverter 规则,在该规则中被转换为 FlinkLogicalJoin。
private class FlinkLogicalJoinConverter
extends ConverterRule(
classOf[LogicalJoin],
Convention.NONE,
FlinkConventions.LOGICAL,
"FlinkLogicalJoinConverter") {
override def convert(rel: RelNode): RelNode = {
val join = rel.asInstanceOf[LogicalJoin]
//转换左子树
val newLeft = RelOptRule.convert(join.getLeft, FlinkConventions.LOGICAL)
//转换右子树
val newRight = RelOptRule.convert(join.getRight, FlinkConventions.LOGICAL)
//创建 FlinkLogicalJoin 节点,Convention 被替换为 FlinkConventions.LOGICAL
FlinkLogicalJoin.create(newLeft, newRight, join.getCondition, join.getJoinType)
}
}
object FlinkLogicalJoin {
val CONVERTER: ConverterRule = new FlinkLogicalJoinConverter
def create(
left: RelNode,
right: RelNode,
conditionExpr: RexNode,
joinType: JoinRelType): FlinkLogicalJoin = {
val cluster = left.getCluster
val traitSet = cluster.traitSetOf(FlinkConventions.LOGICAL).simplify()
new FlinkLogicalJoin(cluster, traitSet, left, right, conditionExpr, joinType)
}
}
FlinkLogicalJoin 会匹配 StreamExecJoinRule 规则,经过这一步转换会得到 StreamExecJoin 节点:
class StreamExecJoinRule
extends RelOptRule(
operand(classOf[FlinkLogicalJoin],
operand(classOf[FlinkLogicalRel], any()),
operand(classOf[FlinkLogicalRel], any())),
"StreamExecJoinRule") {
override def matches(call: RelOptRuleCall): Boolean = {
val join: FlinkLogicalJoin = call.rel(0)
......
// 判断节点是否匹配规则
}
override def onMatch(call: RelOptRuleCall): Unit = {
val join: FlinkLogicalJoin = call.rel(0)
val left = join.getLeft
val right = join.getRight
.......
val providedTraitSet = join.getTraitSet.replace(FlinkConventions.STREAM_PHYSICAL)
val newLeft: RelNode = RelOptRule.convert(left, leftRequiredTrait)
val newRight: RelNode = RelOptRule.convert(right, rightRequiredTrait)
//生成 StreamExecJoin 节点
val newJoin = new StreamExecJoin(
join.getCluster,
providedTraitSet,
newLeft,
newRight,
join.getCondition,
join.getJoinType)
call.transformTo(newJoin)
}
}
经过优化器处理后,得到的逻辑树中的所有节点都应该是 FlinkPhysicRel,这之后就可以用于生成物理执行计划了。首先要将 FlinkPhysicalRel 构成的 DAG 转换成 ExecNode 构成的 DAG,因为可能存在共用子树的情况,这里还会尝试共用相同的子逻辑计划。由于通常 FlinkPhysicalRel 的具体实现类通常也实现了 ExecNode 接口,所以这一步转换较为简单。
在得到由 ExecNode 构成的 DAG 后,就可以尝试生成物理执行计划了,也就是将 ExecNode 节点转换为 Flink 内部的 Transformation 算子。不同的 ExecNode 按照各自的需求生成不同的 Transformation,基于这些 Transformation 构建 Flink 的 DAG。
trait ExecNode[E <: Planner, T] {
/**
* Translates this node into a Flink operator.
*/
def translateToPlan(planner: E): Transformation[T] = {
if (transformation == null) {
transformation = translateToPlanInternal(planner)
}
transformation
}
}
在得到 Transformation 后,利用 Transformation 生成 StreamGraph 后就可以提交 Flink 任务了。根据 Transformation 列表生成 StreamGraph 比较简单,依次将算子添加到 StreamExecutionEnvironment 即可。这里值得一提的一点在于,在 Blink Runner 中,Stream SQL 和 Batch SQL 都基于同样的 Streaming Runtime 架构,统一使用 StreamExecutionEnvironment 和 Transformation DAG。后续社区会统一 Stream 和 Batch 这两种模式的运行时环境、算子和 API 接口,Blink SQL Runner 算是率先的一个尝试。当然,在 Stream 和 Batch 模式下,算子内部的处理逻辑肯定是要单独进行优化的。Batch 任务运行在 StreamExecutionEnvironment 中需要进行一些特殊的设置,如调度模式,Shuffle 模式等等。
public class BatchExecutor extends ExecutorBase {
/**
* Sets batch configs.
*/
private void setBatchProperties(StreamExecutionEnvironment execEnv) {
ExecutionConfig executionConfig = execEnv.getConfig();
executionConfig.enableObjectReuse();
executionConfig.setLatencyTrackingInterval(-1);
execEnv.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);
execEnv.setBufferTimeout(-1);
if (isShuffleModeAllBatch()) {
executionConfig.setDefaultInputDependencyConstraint(InputDependencyConstraint.ALL);
}
}
@Override
public StreamGraph generateStreamGraph(List<Transformation<?>> transformations, String jobName) {
StreamExecutionEnvironment execEnv = getExecutionEnvironment();
setBatchProperties(execEnv);
transformations.forEach(execEnv::addOperator);
StreamGraph streamGraph;
streamGraph = execEnv.getStreamGraph(getNonEmptyJobName(jobName));
// All transformations should set managed memory size.
ResourceSpec managedResourceSpec = NodeResourceUtil.fromManagedMem(0);
streamGraph.getStreamNodes().forEach(sn -> {
if (sn.getMinResources().equals(ResourceSpec.DEFAULT)) {
sn.setResources(managedResourceSpec, managedResourceSpec);
}
});
streamGraph.setChaining(true);
//设置调度模式为 LAZY_FROM_SOURCES_WITH_BATCH_SLOT_REQUEST
streamGraph.setScheduleMode(ScheduleMode.LAZY_FROM_SOURCES_WITH_BATCH_SLOT_REQUEST);
streamGraph.setStateBackend(null);
if (streamGraph.getCheckpointConfig().isCheckpointingEnabled()) {
throw new IllegalArgumentException("Checkpoint is not supported for batch jobs.");
}
if (isShuffleModeAllBatch()) {
streamGraph.setBlockingConnectionsBetweenChains(true);
}
return streamGraph;
}
private boolean isShuffleModeAllBatch() {
//不允许 ShuffleMode 模式为 PIPELINED
String value = tableConfig.getConfiguration().getString(ExecutionConfigOptions.TABLE_EXEC_SHUFFLE_MODE);
if (value.equalsIgnoreCase(ShuffleMode.BATCH.toString())) {
return true;
} else if (!value.equalsIgnoreCase(ShuffleMode.PIPELINED.toString())) {
throw new IllegalArgumentException(ExecutionConfigOptions.TABLE_EXEC_SHUFFLE_MODE.key() +
" can only be set to " + ShuffleMode.BATCH.toString() + " or " + ShuffleMode.PIPELINED.toString());
}
return false;
}
}
除了使用纯 SQL 语句的方式外, Flink 还支持 Table API 编程,对 Table API 的支持主要借助 Table, Operation 和 Expression 等接口。
Operation 和 Expression 是对操作和表达式的抽象,Operation 和 Expression 都有一套各自的类继承层次,可以等同于 Calcite 中的 RelNode 和 RexNode。通过 Table API 接口,可以构建出语法树,这颗 Operation 树最终被转换为 RelNode 树,之后就是进入前面提到的转换和优化逻辑了。
Table 是对于表的抽象,除了 schema 等信息外,其底层对应的是一个 QueryOperaion,
public interface Table {
/**
* Returns the schema of this table.
*/
TableSchema getSchema();
/**
* Returns underlying logical representation of this table.
*/
QueryOperation getQueryOperation();
}
通过 Table API 构建出由 Operation 和 Expression 组成的查询树,例如:
class TableImpl {
@Override
public Table select(String fields) {
//先解析获取 Expression
return select(ExpressionParser.parseExpressionList(fields).toArray(new Expression[0]));
}
@Override
public Table select(Expression... fields) {
List<Expression> expressionsWithResolvedCalls = Arrays.stream(fields)
.map(f -> f.accept(lookupResolver))
.collect(Collectors.toList());
CategorizedExpressions extracted = OperationExpressionsUtils.extractAggregationsAndProperties(
expressionsWithResolvedCalls
);
if (!extracted.getWindowProperties().isEmpty()) {
throw new ValidationException("Window properties can only be used on windowed tables.");
}
//构建 QueryOperation 并以此为基础创建 Table
if (!extracted.getAggregations().isEmpty()) {
QueryOperation aggregate = operationTreeBuilder.aggregate(
Collections.emptyList(),
extracted.getAggregations(),
operationTree
);
return createTable(operationTreeBuilder.project(extracted.getProjections(), aggregate, false));
} else {
return createTable(operationTreeBuilder.project(expressionsWithResolvedCalls, operationTree, false));
}
}
}
而我们在使用 Scala Api 时经常使用如下更方便的形式:
table.select('key, 'value.avg + " The average" as 'average)
这是由于在 flink-table-api-scala 中提供了很多方法和隐式转换,可以直接用于生成 Expression:
trait ImplicitExpressionOperations {
/**
* Returns left plus right.
*/
def + (other: Expression): Expression = unresolvedCall(PLUS, expr, other)
/**
* Specifies a name for an expression i.e. a field.
*
* @param name name for one field
* @param extraNames additional names if the expression expands to multiple fields
* @return field with an alias
*/
def as(name: Symbol, extraNames: Symbol*): Expression =
unresolvedCall(
AS,
expr +: valueLiteral(name.name) +: extraNames.map(name => valueLiteral(name.name)): _*)
//Symbol 转换成 UnresolvedReferenceExpression
implicit def symbol2FieldExpression(sym: Symbol): Expression =
unresolvedRef(sym.name)
}
Operation 和 Expression 实现了访问者模式,通过 QueryOperationConverter 和 RexNodeConverter 转换为 RelNode 和 RexNode。
更正 :在最新的代码中,RexNodeConverter 已更名为 ExpressionConverter。
在这篇文章中,我们主要对 Flink 1.9 版本中 SQL 的整体执行框架进行了介绍。在这个版本中,Flink 提供了两套 SQL Runner,其中 Blink 将会在后续版本中取代已有的 SQL Runner 成为新的标准,因此我们主要是以 Blink Runner 为例介绍 SQL 的解析和优化流程。在后续的文章中,我们将更详细了解元数据管理、 SQL 算子的实现原理、代码生成等具体的实现细节。
参考
Introduction to Apache Calcite
Apache Flink 1.9.0 Release Announcement
ACO.Visualization项目 本项目演示蚁群算法求解旅行商问题的可视化过程,包括路径上的信息素浓度、蚁群的运动过程等。项目相关的代码:https://github.com/anycad/A
关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。 我们不允许提问寻求书籍、工具、软件库等的推荐。您可以编辑问题,以便用事实和引用来回答。 关闭 7 年前。
我需要用Sql数据库制作并包含的PHP票务系统源码用户客户端和管理员。我需要个人 CMS 的这个来源。谢谢你帮助我。 最佳答案 我在不同的情况下使用了 osticket。 这里: http://ost
我的场景:我想在日志文件中写入发生异常的部分代码(例如,发生异常的行前 5 行和行后 5 行 - 或者至少是该方法的所有代码)。 我的想法是用 C# 代码反编译 pdb 文件,并从该反编译文件中找到一
RocketMQ设定了延迟级别可以让消息延迟消费,延迟消息会使用 SCHEDULE_TOPIC_XXXX 这个主题,每个延迟等级对应一个消息队列,并且与普通消息一样,会保存每个消息队列的消费进度
先附上Hystrix源码图 在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和
此篇博客学习的api如标题,分别是: current_url 获取当前页面的url; page_source 获取当前页面的源码; title 获取当前页面的titl
? 1 2
1、前言 作为一个数据库爱好者,自己动手写过简单的sql解析器以及存储引擎,但感觉还是不够过瘾。<<事务处理-概念与技术>>诚然讲的非常透彻,但只能提纲挈领,不能让你
gory"> 目录 运行时信号量机制 semaphore 前言 作用是什么 几个主要的方法 如何实现
自己写的一个评论系统源码分享给大家,包括有表情,还有评论机制。用户名是随机的 针对某一篇文章进行评论 function subcomment() {
一、概述 StringBuilder是一个可变的字符串序列,这个类被设计去兼容StringBuffer类的API,但不保证线程安全性,是StringBuffer单线程情况下的一个替代实现。在可能的情
一、概述 System是用的非常多的一个final类。它不能被实例化。System类提供了标准的输入输出和错误输出流;访问外部定义的属性和环境变量;加载文件和库的方法;以及高效的拷贝数组中一部分元素
在JDK中,String的使用频率和被研究的程度都非常高,所以接下来我只说一些比较重要的内容。 一、String类的概述 String类的声明如下: public final class Str
一、概述 Class的实例代表着正在运行的Java应用程序的类和接口。枚举是一种类,而直接是一种接口。每一个数组也属于一个类,这个类b被反射为具有相同元素类型和维数的所有数组共享的类对象。八大基本树
一、概述 Compiler这个类被用于支持Java到本地代码编译器和相关服务。在设计上,这个类啥也不做,他充当JIT编译器实现的占位符。 放JVM虚拟机首次启动时,他确定系统属性java.comp
一、概述 StringBuffer是一个线程安全的、可变的字符序列,跟String类似,但它能被修改。StringBuffer在多线程环境下可以很安全地被使用,因为它的方法都是通过synchroni
一、概述 Enum是所有Jav中枚举类的基类。详细的介绍在Java语言规范中有说明。 值得注意的是,java.util.EnumSet和java.util.EnumMap是Enum的两个高效实现,
一、概述 此线程指的是执行程序中的线程。 Java虚拟机允许应用程序同时执行多个执行线程。 每个线程都有优先权。 具有较高优先级的线程优先于优先级较低的线程执行。 每个线程可能也可能不会被标记为守
一、抽象类Number 类继承关系 这里面的原子类、BigDecimal后面都会详细介绍。 属性和抽象方法 二、概述 所有的属性,最小-128,最大127,SIZE和BYTES代码比
我是一名优秀的程序员,十分优秀!