这篇文章主要介绍“Java10局部变量类型举例分析”，在日常操作中，相信很多人在Java10局部变量类型举例分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Java10局部变量类型举例分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、重庆小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了鄂伦春免费建站欢迎大家使用！

上下文：陈词滥调和代码可读性

也许日复一日，你希望不再需要重复做一些事情。例如在下面的代码（使用 Java 9 的集合工厂），左边的类型也许会感觉到冗余和平淡。

import static java.util.Map.entry;List cities = List.of("Brussels", "Cardiff", "Cambridge")Map citiesPopulation= Map.ofEntries(entry("Brussels", 1_139_000),entry("Cardiff", 341_000));

这是一个非常简单的例子，不过它也印证了传统的 Java 哲学：你需要为所有包含的简单表达式定义静态类型。再让我们来看看有一些复杂的例子。举例来说，下面的代码建立了一个从字符串到词的柱状图。它使用 groupingBy 收集器将流聚合进 Map 。groupingBy 收集器还可以以一个分类函数为第一个参数建立映射的键和第二个收集器的 (counting()) 键计算关联的数量。下面就是例子：

String sentence = "A simple Java example that explores what Java10 has to offer";Collector> byOccurrence= groupingBy(Function.identity(), counting());Map wordFrequency= Arrays.stream(sentence.split(" ")).collect(byOccurrence);

复杂表达式提取到一个变量或方法来提升代码的可读性和重用性，这是非常有意义的。在这里例子中，建立柱状图的逻辑使用了收集器。不幸地是，来自 groupingBy 的结果类型几乎是不可读的！对于这一点你毫无办法，你能做的只有观察。

最重要的一点是当 Java 中增加新的类库的时候，他们开发越来越多的泛型，这就为开发者引进了更多的公式化代码（boilerplate code），从而带来了额外的压力。上面的例子并不是说明了编写类型就不好。很明显，强制将为变量和方法签名定义类型的操作执行为一种需要被尊重的协议，将有益于维护和理解。然而，为中间表达式声明类型也许会显得无用和冗余。

类型推断的历史

我们已经在 Java 历史上多次看到语言设计者添加“类型推断”来帮助我们编写更简洁的代码。类型推断是一种思想：编译器可以帮你推出静态类型，你不必自己指定它们。

最早从 Java 5 开始就引入了泛型方法，而泛型方法的参数可以通过上下文推导出来。比如

这段代码：

List cs = Collections.emptyList();

可以简化成：

List cs = Collections.emptyList();

然后，在 Java 7 中，可以在表达式中省略类型参数，只要这些参数能通过上下文确定。比如：

Map> myMap = new HashMap>();

可以使用尖括号<>运算符简化成：

Map> userChannels = new HashMap<>();

一般来说，编译器可以根据周围的上下文来推断类型。在这个示例中，从左侧可以推断出 HashMap 包含字符串列表。

从 Java 8 开始，像下面这样的 Lambda 表达式

Predicate nameValidation = (String x) -> x.length() > 0;

可以省略类型，写成

Predicate nameValidation = x -> x.length() > 0;

局部变量类型推断

随着类型越来越多，泛型参数有可能是另一个泛型，这种情况下类型推导可以增强可读性。Scala 和 C# 语言允许将局部变量的类型声明为 var，由编译器根据初始化语句来填补合适的类型。比如，前面对 userChannels 的声明可以写成这样：

var userChannels = new HashMap>();

也可以是根据方法的返回值（这里返回列表）来推断：

var channels = lookupUserChannels("Tom");channels.forEach(System.out::println);

这种思想称为局部变量类型推断，它已经在 Java 10 中引入！

例如下面的代码：

Path path = Paths.get("src/web.log");try (Stream lines = Files.lines(path)){long warningCount= lines.filter(line -> line.contains("WARNING")).count();System.out.println("Found " + warningCount + " warnings in thelog file");} catch (IOException e) {e.printStackTrace();}

在 Java 10 中可以重构成这样：

var path = Paths.get("src/web.log");try (var lines = Files.lines(path)){var warningCount= lines.filter(line -> line.contains("WARNING")).count();System.out.println("Found " + warningCount + " warnings in thelog file");} catch (IOException e) {e.printStackTrace();}

上述代码中的每个表达式仍然是静态类型（即值的类型）：

局部变量 path 的类型是 Path  变量 lines 的类型是 Stream  变量 warningCount 的类型是 long

也就是说，如果给这些变量赋予不同值则会失败。比如，像下面这样的二次赋值会造成编译错误：

var warningCount = 5;warningCount = "6";| Error:| incompatible types: java.lang.String cannot be converted to int| warningCount = "6"

然而还有一些关于类型推断的小问题；如果类 Car 和 Bike 都是 Vehicle 的子类，然后声明

var v = new Car();

这里声明的 v 的类型是 Car 还是 Vehicle？这种情况下很好解释，因为初始化器（这里是 Car）的类型非常明确。如果没有初始化器，就不能使用 var。稍后像这样赋值

v = new Bike();

会出错。换句话说，var 并不能完美地应用于多态代码。

那应该在哪里使用局部变量类型推断呢？

什么情况下局部类型推断会失效？你不能在字段和方法签名中使用它。它只能用于局部变量，比如下面的代码是不正确的：

public long process(var list) { }

不能在不明确初始化变量的情况下使用 var 声明局部变量。也就是说，不能使用 var 语法声明一个没有赋值的变量。下面这段代码

var x;

这会产生编译错误：

| Error:| cannot infer type for local variable x| (cannot use 'var' on variable without initializer)| var x;| ^----^

也不能把 var 声明的变量初始化为 null。实事上，在后期初始化之前它究竟是什么类型，这并不清楚。

| Error:| cannot infer type for local variable x| (variable initializer is 'null')| var x = null;| ^-----------^

不能在 Lambda 表达式中使用 var，因为它需要明确的目标类型。下面的赋值就是错的：

var x = () -> {}| Error:| cannot infer type for local variable x| (lambda expression needs an explicit target-type)| var x = () -> {};| ^---------------^

但是，下面的赋值却是有效的，原因是等式右边确实有一个明确的初始化。

var list = new ArrayList<>();

这个列表的静态类型是什么？变量的类型被推导为 ArrayList