每日一题(删除链表的倒数第N个节点)+java学习
前言:看了下日期，上次写算法是2023.9.18，今天是2023.10.19，隔了差不多一个月(摆烂了一个月了)。笔者痛心疾首，打算开个每日总结栏目，记录并监督自己的算法与cs常规学习。
不知道能坚持多久，如果以后有哪一天没写，希望原因是我似了(
算法顺序来源于代码随想录代码随想录 (programmercarl.com)
19.删除链表的倒数第N个节点
给你一个链表，删除链表的倒数第 n 个结点，并且返回链表的头结点。
进阶：你能尝试使用一趟扫描实现吗？
示例 1：
输入：head = [1,2,3,4,5], n = 2 输出：[1,2,3,5] 示例 2：
输入：head = [1], n = 1 输出：[] 示例 3：
输入：head = [1,2], n = 1 输出：[1]
//删除链表的倒数第N个节点
// Created by 徐昊岩 on 2023/10/19.
//
struct ListNode {
int val;
ListNode *next;
ListNode() : val(0), next(nullptr) {};
ListNode(int x) : val(x), next(nullptr) {}
ListNode(int x, ListNode *next) : val(x), next(next) {}
};
class Solution {
public:
ListNode *removeNthFromEnd(ListNode *head, int n) {
ListNode newhead(0, head);
ListNode *p1 = &newhead; //结构体变量的首地址并不是结构体变量名！
ListNode *p2 = &newhead;
int flag = 0;
for (int i = 0; i < n; i++) {
p1 = p1->next;
}
while (p1->next != nullptr) {
flag = 1;
p1 = p1->next;
p2 = p2->next;
}
p2->next = p2->next->next;
return flag == 0 ? p2->next : head;
}
};
java学习
classpath
classpath是JVM用到的一个环境变量，它用来指示JVM如何搜索class。
因为Java是编译型语言，源码文件是.java，而编译后的.class文件才是真正可以被JVM执行的字节码。因此，JVM需要知道，如果要加载一个abc.xyz.Hello的类，应该去哪搜索对应的Hello.class文件。
所以，classpath就是一组目录的集合，它设置的搜索路径与操作系统相关。例如，在Windows系统上，用;分隔，带空格的目录用""括起来，可能长这样：
C:\work\project1\bin;C:\shared;"D:\My Documents\project1\bin"
在Linux系统上，用:分隔，可能长这样：
/usr/shared:/usr/local/bin:/home/liaoxuefeng/bin
现在我们假设classpath是.;C:\work\project1\bin;C:\shared，当JVM在加载abc.xyz.Hello这个类时，会依次查找：
<当前目录>\abc\xyz\Hello.class
C:\work\project1\bin\abc\xyz\Hello.class
C:\shared\abc\xyz\Hello.class
注意到.代表当前目录。如果JVM在某个路径下找到了对应的class文件，就不再往后继续搜索。如果所有路径下都没有找到，就报错。
classpath的设定方法有两种：
在系统环境变量中设置classpath环境变量，不推荐；
在启动JVM时设置classpath变量，推荐。
我们强烈不推荐在系统环境变量中设置classpath，那样会污染整个系统环境。在启动JVM时设置classpath才是推荐的做法。实际上就是给java命令传入-classpath或-cp参数：
java -classpath .;C:\work\project1\bin;C:\shared abc.xyz.Hello
没有设置系统环境变量，也没有传入-cp参数，那么JVM默认的classpath为.，即当前目录
“.”表示当前目录，是必要的?
有很多“如何设置classpath”的文章会告诉你把JVM自带的rt.jar放入classpath，但事实上，根本不需要告诉JVM如何去Java核心库查找class，JVM怎么可能笨到连自己的核心库在哪都不知道？
不要把任何Java核心库添加到classpath中！JVM根本不依赖classpath加载核心库！
假设我们有一个编译后的Hello.class，它的包名是com.example，当前目录是C:\work，那么，目录结构必须如下：
C:\work
└─ com
└─ example
└─ Hello.class
运行这个Hello.class必须在当前目录下使用如下命令：
C:\work> java -cp . com.example.Hello
JVM根据classpath设置的.在当前目录下查找com.example.Hello，即实际搜索文件必须位于com/example/Hello.class。如果指定的.class文件不存在，或者目录结构和包名对不上，均会报错。
在IDEA中
想要知道classPath具体包含哪些路径，我们应该先看看自己项目的目录结构，点击IDEA左上角的file->Project-Structure.
结构的右边列出了4个项目中的文件类型：
Source Folders：表示的都是代码源文件目录，生成的class文件会输出到target->classess文件夹中，但是里面的源文件不会复制到target->classes文件夹中
Test Source Folders: 表示的都是测试代码源文件目录，生成的class文件同样会输出到target->classess文件夹中，并且里面的源文件不会复制到target->classes文件夹中
Resource Folders: 表示的都是资源文件目录，这些目录里面的文件会在代码编译运行被直接复制到target->classess文件夹中
Excluded Folders:表示的是target文件夹生成的位置，target是IDEA编译后的一些class信息存放地，里面有子目录target->classes来存储编译后的字节码。
target->classes即为classpath路径位置，任何我们需要在classpath：前缀中获取的资源都必须在target->classes文件夹中找到，否则将出现java.io.FileNotFoundException的错误信息。
————————————————
节选自csdn原文链接：关于IDEA中的classpath定义_idea classpath-CSDN博客
jar包
如果有很多.class文件，散落在各层目录中，肯定不便于管理。如果能把目录打一个包，变成一个文件，就方便多了。
jar包就是用来干这个事的，它可以把package组织的目录层级，以及各个目录下的所有文件（包括.class文件和其他文件）都打成一个jar文件，这样一来，无论是备份，还是发给客户，就简单多了。
jar包实际上就是一个zip格式的压缩文件，而jar包相当于目录。如果我们要执行一个jar包的class，就可以把jar包放到classpath中：
java -cp ./hello.jar abc.xyz.Hello
这样JVM会自动在hello.jar文件里去搜索某个类。
那么问题来了：如何创建jar包？
因为jar包就是zip包，所以，直接在资源管理器中，找到正确的目录，点击右键，在弹出的快捷菜单中选择“发送到”，“压缩(zipped)文件夹”，就制作了一个zip文件。然后，把后缀从.zip改为.jar，一个jar包就创建成功。
jar包还可以包含一个特殊的/META-INF/MANIFEST.MF文件，MANIFEST.MF是纯文本，可以指定Main-Class和其它信息。JVM会自动读取这个MANIFEST.MF文件，如果存在Main-Class，我们就不必在命令行指定启动的类名，而是用更方便的命令：
java -jar hello.jar
在大型项目中，不可能手动编写MANIFEST.MF文件，再手动创建zip包。
Java社区提供了大量的开源构建工具，例如Maven，可以非常方便地创建jar包。
class版本
在Java开发中，许多童鞋经常被各种版本的JDK搞得晕头转向，本节我们就来详细讲解Java程序编译后的class文件版本问题。
我们通常说的Java 8，Java 11，Java 17，是指JDK的版本，也就是JVM的版本，更确切地说，就是java.exe这个程序的版本：
$ java -version
java version "17" 2021-09-14 LTS
而每个版本的JVM，它能执行的class文件版本也不同。例如，Java 11对应的class文件版本是55，而Java 17对应的class文件版本是61。
如果用Java 11编译一个Java程序，输出的class文件版本默认就是55，这个class既可以在Java 11上运行，也可以在Java 17上运行，因为Java 17支持的class文件版本是61，表示“最多支持到版本61”。
如果用Java 17编译一个Java程序，输出的class文件版本默认就是61，它可以在Java 17、Java 18上运行，但不可能在Java 11上运行，因为Java 11支持的class版本最多到55。如果使用低于Java 17的JVM运行，会得到一个UnsupportedClassVersionError，错误信息类似：
java.lang.UnsupportedClassVersionError: Xxx has been compiled by a more recent version of the Java Runtime...
只要看到UnsupportedClassVersionError就表示当前要加载的class文件版本超过了JVM的能力，必须使用更高版本的JVM才能运行。
打个比方，用Word 2013保存一个Word文件，这个文件也可以在Word 2016上打开。但反过来，用Word 2016保存一个Word文件，就无法使用Word 2013打开。
但是，且慢，用Word 2016也可以保存一个格式为Word 2013的文件，这样保存的Word文件就可以用低版本的Word 2013打开，但前提是保存时必须明确指定文件格式兼容Word 2013。
类似的，对应到JVM的class文件，我们也可以用Java 17编译一个Java程序，指定输出的class版本要兼容Java 11（即class版本55），这样编译生成的class文件就可以在Java >=11的环境中运行。
指定编译输出有两种方式，一种是在javac命令行中用参数--release设置：
$ javac --release 11 Main.java
参数--release 11表示源码兼容Java 11，编译的class输出版本为Java 11兼容，即class版本55。
第二种方式是用参数--source指定源码版本，用参数--target指定输出class版本：
$ javac --source 9 --target 11 Main.java
上述命令如果使用Java 17的JDK编译，它会把源码视为Java 9兼容版本，并输出class为Java 11兼容版本。注意--release参数和--source --target参数只能二选一，不能同时设置。
然而，指定版本如果低于当前的JDK版本，会有一些潜在的问题。例如，我们用Java 17编译Hello.java，参数设置--source 9和--target 11：
public class Hello {
public static void hello(String name) {
System.out.println("hello".indent(4));
}
}
用低于Java 11的JVM运行Hello会得到一个LinkageError，因为无法加载Hello.class文件，而用Java 11运行Hello会得到一个NoSuchMethodError，因为String.indent()方法是从Java 12才添加进来的，Java 11的String版本根本没有indent()方法。
注：如果使用–release 11则会在编译时检查该方法是否在Java 11中存在。
因此，如果运行时的JVM版本是Java 11，则编译时也最好使用Java 11，而不是用高版本的JDK编译输出低版本的class。
如果使用javac编译时不指定任何版本参数，那么相当于使用--release 当前版本编译，即源码版本和输出版本均为当前版本。
java模块(附带依赖的jar包)与JRE打包(类似于pyinstaller，只打包需要运行的依赖缩小内存)
从Java 9开始，JDK又引入了模块（Module）。
什么是模块？这要从Java 9之前的版本说起。
我们知道，.class文件是JVM看到的最小可执行文件，而一个大型程序需要编写很多Class，并生成一堆.class文件，很不便于管理，所以，jar文件就是class文件的容器。
在Java 9之前，一个大型Java程序会生成自己的jar文件，同时引用依赖的第三方jar文件，而JVM自带的Java标准库，实际上也是以jar文件形式存放的，这个文件叫rt.jar，一共有60多M。
如果是自己开发的程序，除了一个自己的app.jar以外，还需要一堆第三方的jar包，运行一个Java程序，一般来说，命令行写这样：
java -cp app.jar:a.jar:b.jar:c.jar com.liaoxuefeng.sample.Main
注意：JVM自带的标准库rt.jar不要写到classpath中，写了反而会干扰JVM的正常运行。
如果漏写了某个运行时需要用到的jar，那么在运行期极有可能抛出ClassNotFoundException。
所以，jar只是用于存放class的容器，它并不关心class之间的依赖。
从Java 9开始引入的模块，主要是为了解决“依赖”这个问题。如果a.jar必须依赖另一个b.jar才能运行，那我们应该给a.jar加点说明啥的，让程序在编译和运行的时候能自动定位到b.jar，这种自带“依赖关系”的class容器就是模块。
为了表明Java模块化的决心，从Java 9开始，原有的Java标准库已经由一个单一巨大的rt.jar分拆成了几十个模块，这些模块以.jmod扩展名标识，可以在$JAVA_HOME/jmods目录下找到它们：
- java.base.jmod
- java.compiler.jmod
- java.datatransfer.jmod
- java.desktop.jmod
- …
这些.jmod文件每一个都是一个模块，模块名就是文件名。例如：模块java.base对应的文件就是java.base.jmod。模块之间的依赖关系已经被写入到模块内的module-info.class文件了。所有的模块都直接或间接地依赖java.base模块，只有java.base模块不依赖任何模块，它可以被看作是“根模块”，好比所有的类都是从Object直接或间接继承而来。
把一堆class封装为jar仅仅是一个打包的过程，而把一堆class封装为模块则不但需要打包，还需要写入依赖关系，并且还可以包含二进制代码（通常是JNI扩展）。此外，模块支持多版本，即在同一个模块中可以为不同的JVM提供不同的版本。
编写模块
那么，我们应该如何编写模块呢？还是以具体的例子来说。首先，创建模块和原有的创建Java项目是完全一样的，以oop-module工程为例，它的目录结构如下：
oop-module
├── bin
├── build.sh
└── src
├── com
│ └── itranswarp
│ └── sample
│ ├── Greeting.java
│ └── Main.java
└── module-info.java
其中，bin目录存放编译后的class文件，src目录存放源码，按包名的目录结构存放，仅仅在src目录下多了一个module-info.java这个文件，这就是模块的描述文件。在这个模块中，它长这样：
module hello.world {
requires java.base; // 可不写，任何模块都会自动引入java.base
requires java.xml;
}
其中，module是关键字，后面的hello.world是模块的名称，它的命名规范与包一致。花括号的requires xxx;表示这个模块需要引用的其他模块名。除了java.base可以被自动引入外，这里我们引入了一个java.xml的模块。
当我们使用模块声明了依赖关系后，才能使用引入的模块。例如，Main.java代码如下：
package com.itranswarp.sample;
// 必须引入java.xml模块后才能使用其中的类:
import javax.xml.XMLConstants;
public class Main {
public static void main(String[] args) {
Greeting g = new Greeting();
System.out.println(g.hello(XMLConstants.XML_NS_PREFIX));
}
}
如果把requires java.xml;从module-info.java中去掉，编译将报错。可见，模块的重要作用就是声明依赖关系。
下面，我们用JDK提供的命令行工具来编译并创建模块。
首先，我们把工作目录切换到oop-module，在当前目录下编译所有的.java文件，并存放到bin目录下，命令如下：
$ javac -d bin src/module-info.java src/com/itranswarp/sample/*.java
如果编译成功，现在项目结构如下：
oop-module
├── bin
│ ├── com
│ │ └── itranswarp
│ │ └── sample
│ │ ├── Greeting.class
│ │ └── Main.class
│ └── module-info.class
└── src
├── com
│ └── itranswarp
│ └── sample
│ ├── Greeting.java
│ └── Main.java
└── module-info.java
注意到src目录下的module-info.java被编译到bin目录下的module-info.class。
下一步，我们需要把bin目录下的所有class文件先打包成jar，在打包的时候，注意传入--main-class参数，让这个jar包能自己定位main方法所在的类：
$ jar --create --file hello.jar --main-class com.itranswarp.sample.Main -C bin .
现在我们就在当前目录下得到了hello.jar这个jar包，它和普通jar包并无区别，可以直接使用命令java -jar hello.jar来运行它。但是我们的目标是创建模块，所以，继续使用JDK自带的jmod命令把一个jar包转换成模块：
$ jmod create --class-path hello.jar hello.jmod
于是，在当前目录下我们又得到了hello.jmod这个模块文件，这就是最后打包出来的传说中的模块！
运行模块
要运行一个jar，我们使用java -jar xxx.jar命令。要运行一个模块，我们只需要指定模块名。试试：
$ java --module-path hello.jmod --module hello.world
结果是一个错误：
Error occurred during initialization of boot layer
java.lang.module.FindException: JMOD format not supported at execution time: hello.jmod
原因是.jmod不能被放入--module-path中。换成.jar就没问题了：
$ java --module-path hello.jar --module hello.world
Hello, xml!
那我们辛辛苦苦创建的hello.jmod有什么用？答案是我们可以用它来打包JRE。
打包JRE
前面讲了，为了支持模块化，Java 9首先带头把自己的一个巨大无比的rt.jar拆成了几十个.jmod模块，原因就是，运行Java程序的时候，实际上我们用到的JDK模块，并没有那么多。不需要的模块，完全可以删除。
过去发布一个Java应用程序，要运行它，必须下载一个完整的JRE，再运行jar包。而完整的JRE块头很大，有100多M。怎么给JRE瘦身呢？
现在，JRE自身的标准库已经分拆成了模块，只需要带上程序用到的模块，其他的模块就可以被裁剪掉。怎么裁剪JRE呢？并不是说把系统安装的JRE给删掉部分模块，而是“复制”一份JRE，但只带上用到的模块。为此，JDK提供了jlink命令来干这件事。命令如下：
$ jlink --module-path hello.jmod --add-modules java.base,java.xml,hello.world --output jre/
我们在--module-path参数指定了我们自己的模块hello.jmod，然后，在--add-modules参数中指定了我们用到的3个模块java.base、java.xml和hello.world，用,分隔。最后，在--output参数指定输出目录。
现在，在当前目录下，我们可以找到jre目录，这是一个完整的并且带有我们自己hello.jmod模块的JRE。试试直接运行这个JRE：
$ jre/bin/java --module hello.world
Hello, xml!
要分发我们自己的Java应用程序，只需要把这个jre目录打个包给对方发过去，对方直接运行上述命令即可，既不用下载安装JDK，也不用知道如何配置我们自己的模块，极大地方便了分发和部署。
访问权限
前面我们讲过，Java的class访问权限分为public、protected、private和默认的包访问权限。引入模块后，这些访问权限的规则就要稍微做些调整。
确切地说，class的这些访问权限只在一个模块内有效，模块和模块之间，例如，a模块要访问b模块的某个class，必要条件是b模块明确地导出了可以访问的包。
举个例子：我们编写的模块hello.world用到了模块java.xml的一个类javax.xml.XMLConstants，我们之所以能直接使用这个类，是因为模块java.xml的module-info.java中声明了若干导出：
module java.xml {
exports java.xml;
exports javax.xml.catalog;
exports javax.xml.datatype;
...
}
只有它声明的导出的包，外部代码才被允许访问。换句话说，如果外部代码想要访问我们的hello.world模块中的com.itranswarp.sample.Greeting类，我们必须将其导出：
module hello.world {
exports com.itranswarp.sample;
requires java.base;
requires java.xml;
}
因此，模块进一步隔离了代码的访问权限。