异常——JAVA异常（B）

JAVA异常 —— B

此JAVA异常指的是java.lang.Exception的子类，对异常源码中注释的分析主要是基于JDK8。异常顺序是根据异常最终类名的首字母进行排序。本篇主要整理的是B开头的异常。

BackingStoreException

抛出以表示由于后备存储中的故障而无法完成首选项操作，或无法联系后备存储

异常全路径

java.util.prefs.BackingStoreException

异常介绍

首先介绍下java.util.prefs包主要是用来提供对用户和系统首选项配置数据的存储和检索。而出现此BUG的时机大概是JVM对首选项数据进行存储时发生的错误。

解决方法

目前此异常出现的时机，根据大多数的文章显示发生在使用linux环境下tomcat启动时。输出的内容为：

Warning: Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.

这种情况很大概率是因为，tomcat没有操作对应文件权限导致的。

比如这篇文章 解决 java.util.prefs.BackingStoreException 报错问题 中描述的。选择删除对应文件夹(不确定是否有效)或者给予其权限。

• 比如将tomcat配置中的用户设置为tomcat

# tomcat.conf
TOMCAT_USER="tomcat"

• 并为此用户设置相关操作权限

# chown tomcat:tomcat -R /etc/.java/.systemPrefs
# chown tomcat:tomcat -R /etc/.java
# chown tomcat:tomcat -R /var/lock/subsys/tomcat
# chown tomcat:tomcat -R /var/log/tomcat
# chown tomcat:tomcat -R /var/lib/tomcat
# chown tomcat:tomcat -R /var/cache/tomcat
# chown tomcat:tomcat -R /etc/rc.d/init.d/tomcat
# chown tomcat:tomcat -R /etc/logrotate.d/tomcat
# chown tomcat:tomcat -R /etc/sysconfig/tomcat
# chown tomcat:tomcat -R /etc/tomcat
# chown tomcat:tomcat -R /usr/sbin/tomcat
# chown tomcat:tomcat -R /usr/share/tomcat
# chown tomcat:tomcat -R /usr/share/java/tomcat

BadAttributeValueExpException

异常全路径

javax.management.BadAttributeValueExpException

异常介绍

javax.management包按照百科中的描述

Java Management Extensions (JMXTM) API 是一个用于管理和监视的标准 API。典型用途包括： 查询并更改应用程序配置 累积有关应用程序行为的统计并使其可用 通知状态更改及错误状况。 JMX API 还可以作为解决方案的一部分来管理系统、网络等。 API 包括远程访问，因此，远程管理程序可以基于这些目的与正在运行的应用程序交互。

• MBean
  JMX API 的基本概念是 MBean。MBean 是表示资源的指定托管对象。它有一个管理接口，包括以下内容：

1. 可以读取和/或写入的指定名称和类型的属性
2. 可以调用的指定名称和类型的操作
3. 可以由 MBean 发送的指定类型的通知。

这里根据源码中的注解可以推断当传递错误的MBean属性时候出现此异常。而注释中专门指出This exception is used internally by JMX during the evaluation of a query. User code does not usually see it. 此异常为JMX内部使用异常，用户代码一般是见不到的。

解决方法

在日常开发中的确没有见过此异常，而根据源码中可以看到，此异常由接口QueryExp抛出，假如遇见此异常，需要去其apply方法中的逻辑进行排查

public interface QueryExp extends Serializable {
    .....
     public boolean apply(ObjectName name) throws BadStringOperationException, BadBinaryOpValueExpException,
         BadAttributeValueExpException, InvalidApplicationException ;
    ......

 }

BadBinaryOpValueExpException

异常全路径

javax.management.BadBinaryOpValueExpException

异常介绍&解决方法

此异常和上面的javax.management.BadAttributeValueExpException类似，皆是JMX内部异常。并且此异常由接口QueryExp抛出。不同之处此异常表示在使用MBean的时候使用了错误的表达式而导致的。假如遇见此异常需要和上面异常一样需要去其apply方法中的逻辑进行排查。不同之处在于，上一个异常引起原因是参数的错误，此异常时因为表达式的错误。

BadLocationException

异常全路径

javax.swing.text.BadLocationException

异常介绍

当尝试引用文档模型中不存在的位置的时候会抛出此异常。根据网上的资料，很多人出现此异常的时候会输出下面内容

javax.swing.text.BadLocationException: Position not represented by view

出现这种情况,可能是因为在初始化的面板参数和预计的不同，调用面板坐标的时候超过了设置的范围。

比如Stack Overflow上一个问题BadLocationException when using Utilities.getRowStart On hit of Enter key
Ask Question
，在尝试定位偏移量的时候使用了错误的方式导致，定位的坐标和实际范围不同

解决方法

出现此问题，需要检查自己初始化时候文档模型的数据，以及在使用模型中定义的数据是否超出范围。

BadStringOperationException

异常全路径

javax.management.BadStringOperationException

异常介绍&解决方法

此异常和javax.management.BadAttributeValueExpException以及javax.management.BadBinaryOpValueExpException属于同一软件包异常，前者表示参数的错误，后者表示表达式的错误。而这个异常表示的是无效的字符串操作所产生的错误。假如遇见此异常需要和上面异常一样需要去其apply方法中的逻辑进行排查。

BrokenBarrierException

异常全路径

java.util.concurrent.BrokenBarrierException

异常介绍

java.util.concurrent包主要是JAVA并发编程中的工具包。对于经常进行线程操作、并发操作的同学这个包接触的最为频繁。

首先根据注释的描述：

Exception thrown when a thread tries to wait upon a barrier that is in a broken state, or which enters the broken state while the thread is waiting.

此异常发生在线程在等待时进入断开状态的barrier，或者在barrier已经处于断开状态时线程进入等待。

• CyclicBarrier

关于这个Barrier注解中有一句提醒@see CyclicBarrier，所以需要简单了解下CyclicBarrier。

在开发中我们可能有这样一个使用场景，一项任务可能被我们拆分为多个线程来进行处理。但是我们希望在所有线程完成任务后再进行下一步操作，这个时候我们就需要CyclicBarrier来将其他线程进入等待状态，然后当等待的线程数量到达预设的数量后统一放行。

那java.util.concurrent.BrokenBarrierException异常为什么会产生呢？

比如下面这段代码，是一个很简单的CyclicBarrier使用方式的代码。

public class Test {

    /**
     * 线程数
     */
    private static int NUM = 10;


    public static void main(String[] args) {
        /**
         * 突破栅栏时执行的方法
         */
        CyclicBarrier barrier =
                new CyclicBarrier(NUM,() -> System.out.println(Thread.currentThread().getName()+"tripped first barrier"));

        for(int i=0;i<NUM;i++){
            TestCyclicBarrier test=new TestCyclicBarrier(barrier);
            Thread t = new Thread(test);
            t.start();
        }
    }


    static class TestCyclicBarrier implements Runnable {

        /**
         * 突破栅栏时执行的方法
         */
        private CyclicBarrier barrier = null;

        public TestCyclicBarrier(CyclicBarrier barrier) {
            this.barrier = barrier;
        }

        @Override
        public void run() {
            try {
                Random random=new Random();
                int time1 = random.nextInt(2000);
                System.out.println(Thread.currentThread().getName()+":first barrie. num of"+barrier.getNumberWaiting()+" waiting");
                Thread.sleep(time1);
                barrier.await();
                System.out.println(Thread.currentThread().getName()+":first barrie. num of"+barrier.getNumberWaiting()+" sleeping");
            } catch (InterruptedException e) {
                e.printStackTrace();
            } catch (BrokenBarrierException e) {
                e.printStackTrace();
            }
        }
    }

}

在barrier.await();我们将线程等待在这里，但是意外总是可能发现，当有10个线程在执行任务的时候，某个线程因为意外中断，或者因为超时而中断，其就可能导致其他在等待中的线程抛出java.util.concurrent.BrokenBarrierException的异常。

解决方法

产生此异常代表在并发任务过程中，在执行到CyclicBarrier的时候发生的某些意外，这些意外可能还是某一个或多个线程执行任务过重而超时，或者是某一个或多个线程因为程序逻辑上的问题导致任务执行的中断。

1. 针对超时一般需要排查时候存在java.util.concurrent.TimeoutException的错误，必要时需要追踪任务执行时长
2. 而不存在超时异常情况下多数是因为程序上的错误逻辑导致线程的中断，需要根据其他异常信息（假如异常没有被错误的捕获且又遗忘添加提示）来判断问题原因。

---

个人第一次尝试写一些有关技术不一样的内容。但是很多内容受限于本人浅薄的知识以及工作之余稀少的时间导致没法写的更加详细。我只是希望这篇文字能够给阅读他的人带来一些启发，假如有所帮助希望能点一个赞。你的点赞就是我前进的动力。