-
Arrays.binarySearch用于在已排序数组中高效查找元素，1.调用形式为intindex=Arrays.binarySearch(array,key)，返回目标索引或负值；2.未找到时返回-(插入点)-1，表示应插入位置以维持有序；3.可指定搜索范围fromIndex到toIndex（左闭右开），如Arrays.binarySearch(arr,1,4,3)在子区间查找；4.支持基本类型和对象数组，对象比较需实现Comparable或使用Comparator，如String.CASE_INSE
-
先设置全局JDK再配置默认项目选项。打开ProjectStructure添加JDK，进入NewProjectsSetup设置ProjectSDK和languagelevel，再在Compiler中设定字节码版本，确保新建项目自动使用指定Java版本。
-
LinkedList最适合频繁在头尾增删元素的场景，因其addFirst、removeLast等操作均为O(1)；但随机访问慢、内存占用大、缓存不友好，不宜用于大数据量索引查找。
-
本文详解LeetCode1389题「创建目标数组」的正确解法：根据索引数组index中指定的位置，将nums中的元素逐个插入到动态增长的目标数组中，关键在于使用ArrayList.add(intindex,Eelement)实现O(1)平均复杂度的中间插入。
-
使用toArray()方法可将集合转为数组，推荐调用带参数的toArray(T[])并传入长度为0的目标类型数组（如newString[0]），以确保类型安全且性能更优。
-
抽象类不能被实例化，因其表达不完整概念（如Animal），编译器禁止new操作；它通过abstract方法强制子类实现，通过具体方法复用逻辑，并支持状态共享、构造初始化和继承约束。
-
Path比File更灵活，能跨平台处理路径逻辑；Files类封装90%以上基础IO操作，提供walk()高效遍历和清晰异常体系。
-
Java轻量推荐功能可用协同过滤、内容匹配和热度兜底三策略实现：用HashMap存用户行为并按交集算相似度；依标签重合匹配物品；冷启动时以加权热门队列补足，辅以Caffeine缓存与统一接口设计。
-
在SpringBoot项目中整合Swagger的核心步骤包括：引入依赖、配置DocketBean、添加注解以实现API文档化，并可通过安全认证和隐藏接口等进一步优化。1.引入Maven依赖，推荐使用springfox-boot-starter3.0.0版本；2.创建配置类SwaggerConfig，定义DocketBean并设置API基本信息、扫描路径和包；3.启动应用后访问/swagger-ui/index.html查看文档界面；4.添加securitySchemes和securityContexts以
-
Thread类是Java多线程核心，start()启动新线程并执行run()；sleep()使当前线程休眠且不释放锁；join()让当前线程等待目标线程结束；currentThread()等方法用于获取线程信息与状态。
-
UnsupportedOperationException是运行时异常，用于表示操作不被支持，常见于部分实现的接口或不可变集合，可通过thrownewUnsupportedOperationException("消息")手动抛出，并建议提供清晰的异常信息以增强代码可维护性。
-
Java对象默认分配在堆上，但逃逸分析可使未逃逸对象栈上分配或标量替换；对象头含MarkWord和KlassPointer，字段按类型重排并8字节对齐；TLAB优化内存分配，new慢主因是初始化与GC压力。
-
JavaMailAPI发送邮件前必须确认的三件事不配对SMTP服务器和认证方式，代码跑得再顺也发不出去。JavaMail不是“写完就能发”，它本质是把你的邮件内容打包成标准协议数据，扔给SMTP服务器——而这个服务器是否接受你、是否要登录、走不走TLS，全由你填的配置决定。host和port必须匹配：比如用smtp.gmail.com就不能配25端口（默认被禁），得选587（STARTTLS）或465（SSL）大多数现代邮箱（Gmail、Outlook、QQ邮箱
-
多线程核心价值是提升CPU利用率和整体吞吐量，通过让等待I/O的线程释放CPU给其他任务执行；需用线程池复用线程，避免频繁创建销毁；共享变量须用volatile、synchronized或AtomicInteger等机制同步；线程协作优先选用BlockingQueue、CountDownLatch等高级并发工具。
-
活锁现象怎么一眼认出来程序没卡死，线程都在跑，CPU占用正常，但业务逻辑就是不往前走——比如两个线程反复回退重试、互相谦让资源，Thread.getState()一直显示RUNNABLE，日志里却不断刷出“重试第1次”“重试第2次”……这不是死锁，是典型的活锁。常见于基于乐观锁的重试逻辑，比如用AtomicInteger.compareAndSet()或JPA的@Version字段更新失败后立刻重试，又没加延迟或退避机制。为什么固定间隔重试反而加剧活锁多个线程在相同节奏
